нужен совет по оптимизации конфигурации кластера

Главная Форумы High Availability PowerHA (HACMP) нужен совет по оптимизации конфигурации кластера

Просмотр 24 веток ответов
  • Автор
    Сообщения
    • #17908
      Sergey
      Участник

      Всем добрый вечер.

      Я только недавно начал осваивать технологии Виртуализации, HACMP и SAN и их реализацию на оборудовании IBM в частности, поэтому хотелось бы посоветоваться с более опытными коллегами.

      Для начала опишу ситуацию…

      Текущая конфигурация (сделано ещё до меня):
      DATACENTER_1 (основной): Power6_595_1 + DS8300_1 + 2xFC switch + 2xEthernet switch
      DATACENTER_2 (резервный): Power6_595_2 + DS8300_2 + 2xFC switch + 2xEthernet switch

      LPARы на 595-х серверах находятся в кластере HACMP в режиме active/passive
      DSы работают в режиме Mirror т.е. все LUNы DS_1 активного плеча кластера, синхронно, зеркалируются на DS_2 пассивного плеча кластера, во время Failover на DATACENTER_2 зеркало разворачивается в обратном направлении и соответственно LUNы подключаются уже с DS_2.

      Проблемы:
      1. При максимальной рабочей нагрузке, LPARы задействуют почти все ресурсы сервера, особенно RAM, из-за чего страдает быстродействие приложений.
      2. При необходимости переехать с одного плеча кластера на другое, процесс может занимать достаточно значительное время – до 20 минут (хотя, казалось бы, задача кластера как раз и заключается в том, чтобы не было простоя).
      3. Во время последней аварии, когда DATACENTER_1 оказался полностью изолирован от мира как по IP так и по FC, текущая конфигурация показала абсолютную неспособность обеспечить бесперебойную работу кластера так как переезд в автоматическом режиме не произошёл.
      Как я понял, причина, того что переезд не случился в автоматическом режиме, заключалась в том, что при инициализации clRGmove HACMP запускает скрипты, один из которых, через DSCLI команды, разворачивает зеркалирование DS массивов т.е массив который был источником должен стать таргетом и соответственно наоборот.
      При невозможности развернуть зеркало на DSах, HACMP не может примонтировать LUNы на активируемой стороне кластера. А так как при аварии SHMC на DS_1 был недоступен, кластер встал.

      Мои соображения по решению проблем и вопросы:
      1. Переконфигурировать кластер в режим Active/Active. Распределить LPARы с приложениями по обоим 595-м серверам в равной степени. Это позволит выделить больше ресурсов под каждый LPAR и соответственно должно решить проблему быстродействия.
      В правильном ли направлении я мыслю? Какие будут рекомендации по практической реализации?

      2. По данному пункту пока ничего в голову не приходит. Я так понимаю, что это нормальное поведение HACMP?? Или всё таки что то можно предпринять?

      3. Каким образом можно обеспечить отказоустойчивость кластера если, при недоступности SHMC DSа в аварийном датацентре, HACMP не может развернуть связь источник-таргет между DSми и примонтировать LUNы на активируемой стороне кластера?
      Думаю переписать скрипт чтобы он принудительно делал доступный DS источником и ставил зеркало в suspend. Что скажете коллеги?

    • #17909
      azar_mike
      Участник

      Виртуализуй две DS8300 через IBM SVC, положи копию каждого lun на обе DS8300.
      Отпадет надобность в Enhanced Remote Mirroring, кластер должен быстрее переключаться.

    • #17910
      uxTuaHgp
      Участник

      Извините, но это в юмор.

      1. Кто сказал, что память съедается, и как это влияет на производительность? Нужно умерить аппетит приложений, т.к. явно они неправильно сконфигурированы, раз потребляют всю память и еще немножко, видимо из свопа.
      Развести активные LPAR по DC поможет в балансировке нагрузки на CPU, но не на RAM, если только не баловаться с динамическим перераспределением ресурсов при переезде кластера – это сделает переезд кластера еще более долгим. Или у вас на одном LPAR несколько приложений не связанных?

      2. Тестирование кластера вам ответило бы на вопрос о заачах кластера, а переключение руками не показывает ничего, потому что кластер скриптами аккуратно кладет приложение, синкает кэш, размонтирует файловые системы и тд и тп. При эмуляции сбоя или при реальном сбое этого не происходит и кластер переезжает за 2-5 минут в зависимости от приложения.

      А по существу единственной проблемы номер 3: нужно не просто switch паре делать видимо, а с форсом разламывать пару при разрыве связи между DC. Я не специалист по DS8000.
      Либо разбирайтесь с DSCLI и событиями кластера либо наверное все таки докупайте HACMP XD, который умеет сам работать с RemoteMirror на DS8000. Само собой в скриптах нужно проверять доступность HMC DS8000 конкретного, а правильнее будет обращаться к тому что рядом – вы ведь хотите активировать именно ближнюю к себе половинку зеркала.
      Вообще, думаю, что настраивал кластер не прежний админ, а интеграторы. Берите за жабры руководство, поднимайте протоколы тестирования кластера при сдаче системы в эксплуатацию, заставляйте интеграторов тестировать заново и устранять недостатки.

    • #17911
      Sergey
      Участник

      Виртуализуй две DS8300 через IBM SVC, положи копию каждого lun на обе DS8300.
      Отпадет надобность в Enhanced Remote Mirroring, кластер должен быстрее переключаться.

      Идея конечно заманчивая, но в нашей конфигурации наверное через чур избыточна.

    • #17912
      Sergey
      Участник

      Извините, но это в юмор.

      1. Кто сказал, что память съедается, и как это влияет на производительность? Нужно умерить аппетит приложений, т.к. явно они неправильно сконфигурированы, раз потребляют всю память и еще немножко, видимо из свопа.
      Развести активные LPAR по DC поможет в балансировке нагрузки на CPU, но не на RAM, если только не баловаться с динамическим перераспределением ресурсов при переезде кластера – это сделает переезд кластера еще более долгим. Или у вас на одном LPAR несколько приложений не связанных?

      Я тоже склоняюсь к мнению что аппетит приложений нужно умерить, а то память потребляют да и своп и не немножко. Сейчас занимаемся сбором данных для общения с разработчиком.
      С CPU особо проблем нет используется динамическое перераспределение, загрузка не превышает 45% от общего пула. А вот для RAM динамическое распределение почему то не было настроено. Думаю, что стоит этим заняться.
      По поводу переконфигурирования кластера из Active/Passive в Active/Active Вы наверное меня не совсем поняли.

      Текущая конфигурация – Active/Passive:
      DC1 | DC2
      LPAR_1: APP_1_Active | LPAR_1: APP_1_Passive
      LPAR_2: APP_2_Active | LPAR_2: APP_2_Passive
      LPAR_3: DB_1_Active | LPAR_3: DB_1_Pasive
      LPAR_4: DB_2_Active | LPAR_4: DB_2_Pasive

      Рассматриваемя конфигурация – Active/Active
      DC1 | DC2
      LPAR_1: APP_1_Active; APP_2_Passive | LPAR_1: APP_2_Active; APP_1_Passive
      LPAR_2: DB_1_Active; DB_2_Passive | LPAR_2: DB_2_Active; DB_1_Passive

      Не уж-то эта конфигурация не будет более производительной?

      2. Тестирование кластера вам ответило бы на вопрос о заачах кластера, а переключение руками не показывает ничего, потому что кластер скриптами аккуратно кладет приложение, синкает кэш, размонтирует файловые системы и тд и тп. При эмуляции сбоя или при реальном сбое этого не происходит и кластер переезжает за 2-5 минут в зависимости от приложения.

      Согласен, тестирование нужно обязательно. Есть ли наработанная методика ?

      А по существу единственной проблемы номер 3: нужно не просто switch паре делать видимо, а с форсом разламывать пару при разрыве связи между DC. Я не специалист по DS8000.
      Либо разбирайтесь с DSCLI и событиями кластера либо наверное все таки докупайте HACMP XD, который умеет сам работать с RemoteMirror на DS8000.

      Спасибо за совет, поизучаю.

      Вообще, думаю, что настраивал кластер не прежний админ, а интеграторы. Берите за жабры руководство, поднимайте протоколы тестирования кластера при сдаче системы в эксплуатацию, заставляйте интеграторов тестировать заново и устранять недостатки.

      Этот пункт к сожалению не выполним. Того руководства уже нет, да и как я понял рычагов воздействия на интегратора тоже нет. Так что придётся как то без ансамбля.

    • #17913
      uxTuaHgp
      Участник

      1. Пулами общей памяти не пользуюсь и как вы ее делить собираетесь между партициями что-то не пойму.
      Что вы имели в виду?
      Можно конечно ее с помощью DLPAR передавать туда сюда, но это процесс очень длительный.
      Проще определить дефицит и таки найти перезаклады в потреблении памяти ораклом к примеру или SAP, если у вас он есть и поджать параметры, чтобы система не свопила никогда.

      Перетащить часть активных инстанций на DC2 – хорошо, но к дефициту памяти это как относится? При переезде кластера опчть же придется делиться.

      2. Тестировать эмулируя разные видя сбоев:
      – падение хоста
      – пропадание СХД (зонингом например)
      – пропадание сети

      С продуктивами и RemoteMirror дорогое удовольствие, конечно разламывать пары и потом их обратно синхронизировать, но в каком-то виде это нужно делать.

      Рычаги находятся: интегратор наверняка захочет вам что-то еще продать и не станет портить отношения с хорошим клиентом из-за такой ерунды, к тому же претензии обоснованные – кластер не работает как положено.

    • #17917
      Sergey
      Участник

      1. Пулами общей памяти не пользуюсь и как вы ее делить собираетесь между партициями что-то не пойму.
      Что вы имели в виду?
      Можно конечно ее с помощью DLPAR передавать туда сюда, но это процесс очень длительный.
      Проще определить дефицит и таки найти перезаклады в потреблении памяти ораклом к примеру или SAP, если у вас он есть и поджать параметры, чтобы система не свопила никогда.

      Перезаклад по некоторым нодам есть, но тут не всё так просто – 80% времени может быть перезаклад, но вот как приспичит и что делать?
      Есть ещё тестовые LPARы для разработчиков, которые большую часть времени простаивают и без DLPAR память выделенная этим нодам никак не используется, а перераспределение требует перезагрузки, а если потом назад перераспределить потребуется..
      Я так думаю, что без экспериментов, выяснить как оно будет лучше не получится.
      А есть где нибудь почитать о практике DLPAR (не redbook, а reallife так сказать)?

      Перетащить часть активных инстанций на DC2 – хорошо, но к дефициту памяти это как относится? При переезде кластера опчть же придется делиться.

      Ну, моя логика такая – аварии случаются не каждый день, поэтому зачем простаивать мощностям если их можно задействовать и работать комфортно большую часть времени. Или есть ещё нюансы?

    • #17918
      uxTuaHgp
      Участник

      Не понял.
      DLPAR – это функция доступная любому правильно сконфигурированному LPAR, если PowerVM лицензирована.
      Если есть возможность и есть явные регулярные интервалы времени, когда память может двигаться – попытайтесь, но я бы этим не стал заниматься.
      Нужно апликухи загнать в имеющийся объем так, чтобы не жрали лишнего.

      По поводу логики с простоем ресурсов: это не совсем головная боль администратора.
      Приоритеты ставит бизнес. Если Бизнес сказал, что восстановление сервиса после утраты ЦОД должно происходить в течение 2-х минут, значит это и нужно реализовать.
      А передача памяти с помощью DLPAR может занять и 30 и 40 и минут и час в зависимости от объема и того как она использовалась.
      Все кластеризованные партиции в случае аварии должны жить без свопа на одном 595.
      Памятью можно поиграть только убив тестовые некритичные партиции, опять же, если это одобрит бизнес.

    • #17919
      Sergey
      Участник

      Вот я и спрашиваю, где найти эту информацию по DLPAR относительно RAM. У нас DLPAR работает применительно к пулу процессоров. Для RAM эта функция просто не сконфигурирована, но я так понимаю что доступна. Из того что я видел по распределению процессоров – fold/unfold CPU не занимает особо много времени (секунды), конечно возможно это из-за того что в пуле есть доступные CPU. Так почему с RAM это будет проблемой? Или я не понимаю что такое DLPAR? и может мы можем без перезагрузки перераспределять RAM между LPARми?

    • #17920
      uxTuaHgp
      Участник

      Если речь о командной строке HMC то читать книжку по виртуализации на Power5 – она даже на русском есть.
      Гуглить chhwres

    • #17921
      andrewk
      Участник

      fold/unfold – это не DLPAR. Вы путаете понятия.

    • #17922
      Sergey
      Участник

      fold/unfold – это не DLPAR. Вы путаете понятия.

      Что посоветуете почитать для просветления?

    • #17925
      andrewk
      Участник

      я бы посоветовал для начала курсы, но Вы же не послушаетесь 😉 Поэтому читайте сначала http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247940.html?OpenDocument

    • #17926
      yota
      Участник

      Из того что я видел по распределению процессоров – fold/unfold CPU не занимает особо много времени (секунды), конечно возможно это из-за того что в пуле есть доступные CPU. Так почему с RAM это будет проблемой?

      CPU действительно быстро добавляются/удаляются, а вот с RAM это не так.

    • #17941
      Alex Kovalev
      Участник

      1. По поводу этой проблемы, нужно смотреть использование памяти приложениями. Тут либо настраивать приложения, если возможно на меньшие параметры, либо перераспределять память между LPARами внутри сервера. Разносить нагрузку между сайтами не всегда самая простая задача. Тут могут быть и проблемы связанные с недоступностью сети между площадками по разным причинам. В итоге возможно проблемы будут другого плана, но чаще возникать. От этого возможны соот-щие реакции кластера. Стоит это учитывать.
      2. Переезд в 20 минут это нормально для Enterprise приложений (Oracle, SAP, Documentum и пр) даже в локальном кластере, не говоря уже о межсайтовом. Такие показатели обычно фиксируются, когда нет особой нагрузки. При большой нагрузке переключение может занимать пол часа и больше. Когда происходит сбой (отказ площадки или сайта), переезд возможно занимает меньшее время (опять же не нужно укладывать корректно приложения, если они уже упали самостоятельно). Не стоит ожидать от высоконагруженных приложений переезда за минуту или за секунды. Это из области фантастики.
      3. При недоступности сайта (иначе говоря площадки), другой сайт должен (основываясь на своих событиях) отреагировать переездом без использования ресурсов сбойного сайта. Например, если массив одного сайта перестал видеть массив другого сайта, он вполне может активировать диски для приложений, даже если обратная репликация не возобновилась.

    • #17942
      uxTuaHgp
      Участник

      А вот скажите мне, кто шарит в репликации на DS8000 и SVC: есть там в CLI команда на все случаи жизни, которая при наличии связи между СХД выполняет switch, а при отсутствии связи – делает из Secondary тома Primary с форсом разламывая пару?

    • #17943
      Alex Kovalev
      Участник

      Есть на SVC команды: stoprcrelationship/startrcrelationship/mkrcrelationship/switchrcrelationship

    • #17944
      uxTuaHgp
      Участник

      то что есть такие команды – ясно, но это куча команд, которые можно использовать только после анализа состояния пар.
      У Хитачи, например, кроме кучи различных команд для ручного управления, есть единственная команда horctakeover на все случаи жизни, которая сама анализирует и в зависимости от состояния либо переворачивает либо разрывает пару.

    • #17977
      Alex
      Участник

      есть там в CLI команда на все случаи жизни

      Мне такая постановка вопроса кажется странной, потому что бремя решения должно быть за человеком 😉 Мало ли, что сейчас связи нет – может она появится через минуту. Или была только что, но пропала непосредственно перед переключением, потому что торопыжка рубильником дёрнул раньше.

      Тем не менее, в DS8K близкое к искомому будет: failoverpprc + failbackpprc. Первое инициирует failover, переводя secondary тома в primary (пути между массивами и сам primary массив при этом могжет быть недоступен).

      Второе восстанавливает репликацию (в любом направлении).

    • #17979
      uxTuaHgp
      Участник

      Меня всегда такие заявления о бремени решений как-то озадачивают.
      Дураки придумали мультисайт кластеры с автоматическим failover и вообще все системы высокой доступности :laugh:

    • #17980
      Alex
      Участник

      А как одно с другим коррелирует вообще? “Кластер с автоматическим фейловером” работает так, как захотел функциональный заказчик.

      Мы же ведём речь о cli-шных командах в контексте ручного их введения админом.

    • #17982
      uxTuaHgp
      Участник

      А кластер по мановению волшебной палочки пары переключает? Не через CLI?

    • #17983
      Alex
      Участник

      Так если всё “автоматически”, как сказано выше, какая разница, одна там команда или две? Хоть пятьдесят.

      Количество команд, как мне казалось, имеет смысл только в контексте ручного введения.

    • #17984
      uxTuaHgp
      Участник

      Не, ну если вдруг у меня нет PowerHA XD, но очень хочется подобия мультисайт кластера :laugh:

    • #17988
      Ihar
      Участник

      В CLI есть команда, делающая схд в ERM паре ведущей. Мы при поднятии ресурса на в Pre-event get_disk_vg_fs (но я не уверен из дома пишу)
      Причём, если выполнить её на ведущем схд, то ничего не происходит. Мы это дело изучили, получили подтверждение из IBM support, настроили и протестировали. Единственное (тьфу-тьфу-тьфу) пока в жизни не пригодтлось.

Просмотр 24 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.