Продолжение статьи.
Начало: часть 1
3. Аппаратура и встроенные программы
Данный уровень реализации системы управления характеризуется очень большой свободой выбора для разработчика. Поскольку мы выше договорились не рассматривать в данной статье специализированные аппаратные решения, ограничимся серийной аппаратурой общего назначения.
Прежде всего, по нашему глубокому убеждению, никакая серьёзная статья об отказоустойчивости немыслима без отдачи дани уважения фирме IBM и платформам z Systems и Power Systems. Мейнфреймы z Systems и кластеры Power Systems HA специально спроектированы таким образом, чтобы обеспечить на аппаратном, микропрограммном и системном программном уровне единую отказоустойчивую платформу для приложений пользователя, и по надёжности потенциально превосходят те решения, которые можно реализовать на более распространённой архитектуре Intel. К сожалению, упомянутые решения IBM имеют также определённые недостатки, наиболее общим из которых является их стоимость. Опыт разработчиков показывает, что, при современной стоимости z, p и Intel-решений (самого железа и лицензионных программ для него), а таже при теперешнем курсе доллара к рублю, достаточно сложно в российских условиях экономически оправдать новые вложения в проприетарные архитектуры, даже с учётом значительных дополнительных трудозатрат на обеспечение заданных показателей надёжности у решений Intel. В общем, коллеги, работающие с “большим железом” сами хорошо знают свои резоны, их путь весьма уважаем, но не может быть рекомендован новичку.
Рассматривая Intel-совместимые решения в области отказоустойчивых аппаратных средств, следует обратить внимание, в частности, на следующие моменты:
– горячее резервирование серверов;
– горячее резервирование сетевого оборудования и соединений между серверами;
– горячее резервирование дисковой памяти в системе хранения данных;
– устойчивость встроенного программного обеспечения к сбоям;
– контроль рабочего состояния ОС.
Удобной готовой платформой для горячего резервирования серверов, сетевого оборудования и дисковой памяти являются блейд- и флекс-системы, выпускаемые рядом производителей. Автор склонен рекомендовать подобную систему начинающим разработчикам отказоустойчивых решений (если позволяет бюджет), так как в ней производителем заранее решены многие вопросы, которые иначе могут возникнуть только с приобретением горького опыта. В то же время, горячее резервирование может быть обеспечено и путём комплексирования отдельно монтируемых компонентов. Следует отметить, что, так или иначе, необходимо решать вопрос организации централизованной системы хранения данных с альтернативным доступом для исключения единой точки отказа при выходе из строя подсистемы обращения к данным.
Устойчивость встроенного программного обеспечения к сбоям обеспечивается специальными алгоритмами прошивки UEFI и сервисных контроллеров на серверных платформах. Например, для серверов могут обеспечиваться автоматическое резервирование и восстановление прошивок аппаратуры, автоматическое резервирование загрузчика операционной системы и т.п.
Принципиально важным для обеспечения отказоустойчивости вычислительной среды является использование разного рода сторожевых таймеров, реализуемых серверными платформами. На уровне прикладных программ и кластерного программного обеспечения используется предоставляемый аппаратурой сторожевой таймер IPMI или iTCO. При загрузке операционной системы ряд серверных платформ позволяет установить собственные таймеры, контролирующие успешность этого процесса.
Однажды автору довелось наблюдать поведение блейд-сервера фирмы Lenovo, при обновлении загрузчика операционной системы на котором произошёл сбой, и файлы конфигурации загрузчика записались с ошибкой. Загрузчик начинал грузить ядро Linux, после чего зависал. Через некоторое время в сервисном процессоре сервера срабатывал таймаут загрузки ОС, и сервер перезагружался. Прошивка UEFI сервера, обнаружив, что предыдущая попытка загрузки завершилась неуспехом, самостоятельно принимала решение об откате к предыдущей версии загрузчика из архивного каталога, вызывала его, и система благополучно загружалась. Так система, которая на обычной платформе уровня рабочей станции была бы неоперабельной до ручной загрузки с ремонтного раздела, на серверной платформе благополучно автоматически загружалась в два приёма, до тех пор, пока следующим обновлением не был восстановлен правильный загрузчик. От администратора при первоначальной настройке системы требовалось только выставить корректное значение таймера загрузки.
К широко известным средствам обеспечения отказоустойчивости серверов относятся память ЕСС, объединение дисковых носителей в избыточные RAID массивы, дублирование всех компонентов серверов и серверных шасси, обеспечение альтернативных путей связи между компонентами серверной системы и пр.
Резюмируя, в настоящее время на рынке представлено достаточное разнообразие специализированных серверных систем, аппаратными возможностями которых по обеспечению отказоустойчивости не следует пренебрегать.
Напоследок, отметим распространённое заблуждение – мнение, что минимальный отказоустойчивый кластер должен состоять из трёх узлов, так как это наименьшее число, предусматривающее резервирование и при этом обеспечивающее мажоритарное голосование при выходе одного из узлов из строя. В действительности, выход из строя или перевод в обслуживание одного узла из трёх оставляет оставшиеся два узла в крайне неустойчивом состоянии взаимной конкуренции, которое с большой вероятностью может закончиться их взаимным отстрелом при малейшем сбое связи или при вводе в действие обратно третьего узла, который начнёт устанавливать с ними отношения поочерёдно. Поэтому реальная отказоустойчивая конфигурация кластера должна включать минимум 4 или 5 узлов (вероятность голосования 2:2, и сама по себе очень низкая, так как подразумевает одновременные проблемы на двух узлах, может быть исключена несимметричной топологией кластера).
4. Хостовая операционная система
Вопрос выбора хостовой операционной системы для отказоустойчивых приложений обнаруживает крайнюю зависимость от ряда привходящих моментов. К основным факторам, играющим роль в этом выборе, можно отнести следующие:
– поддержка физического оборудования;
– поддержка среды виртуализации и кластеризации;
– стоимость;
– требования по сертификации и защищённости.
Отказоустойчивые серверные платформы заявляются производителем как совместимые только с небольшим количеством операционных систем. В типичном случае, к таким системам для Intel-совместимых платформ относятся Windows, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES) и VMware ESXi. Установка других операционных систем возможна, но, как правило, приводит к отсутствию штатной поддержки критичных для обеспечения отказоустойчивости аппаратных возможностей (например, средств multipath для резервирования дисковых контроллеров).
Выбор Windows в качестве платформы для построения системы управления, по существу, означает помещение управляющих серверов в концентрированную агрессивную среду злонамеренного программного обеспечения, распространяющегося через аппаратуру неквалифицированных пользователей. С точки зрения автора, такой выбор вряд ли может быть оправдан.
Основными используемыми на сегодняшний день средствами серверной виртуализации для Unix-совместимых систем являются VMware ESXi, KVM (RHEL и SLES), Xen (SLES). Все эти платформы обеспечивают кластеризацию виртуальных машин (в качестве дополнительной опции), то есть поддержку автоматической миграции виртуальных машин с вышедшего из строя узла на резервный.
По функциональным характеристикам гипервизора, на сегодняшний день лидирующее положение занимает VMware ESXi. Однако, стоимость лицензий VMware для кластера высокой готовности, с характерным для него значительным количеством процессоров, может оказаться весьма существенной.
KVM и Xen представляют собой решения попроще и подешевле. К достоинствам KVM относится бо?льшая проработанность ряда интерфейсов виртуальных машин, к достоинствам Xen – функционирование на микроядре, что, теоретически, увеличивает надёжность работы гипервизора.
Наконец, отметим, что требования по сертификации и защищённости, действующие в отрасли, для которой предназначается разрабатываемая отказоустойчивая система, могут перечеркнуть всё вышесказанное, так как ни одна из перечисленных операционных систем может не обеспечивать выполнение требований отраслевых стандартов. В таком случае, при разработке придётся плясать от требований нормативных документов.
Окончание: часть 3
Начало: часть 1
3. Аппаратура и встроенные программы
Данный уровень реализации системы управления характеризуется очень большой свободой выбора для разработчика. Поскольку мы выше договорились не рассматривать в данной статье специализированные аппаратные решения, ограничимся серийной аппаратурой общего назначения.
Прежде всего, по нашему глубокому убеждению, никакая серьёзная статья об отказоустойчивости немыслима без отдачи дани уважения фирме IBM и платформам z Systems и Power Systems. Мейнфреймы z Systems и кластеры Power Systems HA специально спроектированы таким образом, чтобы обеспечить на аппаратном, микропрограммном и системном программном уровне единую отказоустойчивую платформу для приложений пользователя, и по надёжности потенциально превосходят те решения, которые можно реализовать на более распространённой архитектуре Intel. К сожалению, упомянутые решения IBM имеют также определённые недостатки, наиболее общим из которых является их стоимость. Опыт разработчиков показывает, что, при современной стоимости z, p и Intel-решений (самого железа и лицензионных программ для него), а таже при теперешнем курсе доллара к рублю, достаточно сложно в российских условиях экономически оправдать новые вложения в проприетарные архитектуры, даже с учётом значительных дополнительных трудозатрат на обеспечение заданных показателей надёжности у решений Intel. В общем, коллеги, работающие с “большим железом” сами хорошо знают свои резоны, их путь весьма уважаем, но не может быть рекомендован новичку.
Примечание для госсектора
Здесь мы вынуждены сделать развилку в логике нашего изложения, и учесть тот факт, что значительная доля рынка отказоустойчивых систем в России ориентирована на потребности государственного сектора. Поэтому для разработчиков, обременённых, кроме прочих забот, почётными обязанностями по обслуживанию пожеланий государства, заметим следующее. В настоящее время, как известно, Правительством РФ провозглашена политика импортозамещения. В своей наиболее принципиальной форме эта политика подразумевает исключительное использование продукции производства России и стран ЕАЭС. Однако, ряд руководящих документов устанавливает более мягкие требования, диктующие ограничение использования продукции только стран НАТО, Европейского Союза и других, поддерживающих режим секторальных санкций в отношении РФ. Для сферы информационных технологий существенно, что под режим таких мягких ограничений не подпадают КНР (включая Тайвань) и Япония, что выводит в первые ряды для рассмотрения серверные системы компаний Lenovo (весьма удачно перекупившей к выходу соответствующего постановления Intel-совместимый бизнес IBM) и Fujitsu.
Рассматривая Intel-совместимые решения в области отказоустойчивых аппаратных средств, следует обратить внимание, в частности, на следующие моменты:
– горячее резервирование серверов;
– горячее резервирование сетевого оборудования и соединений между серверами;
– горячее резервирование дисковой памяти в системе хранения данных;
– устойчивость встроенного программного обеспечения к сбоям;
– контроль рабочего состояния ОС.
Удобной готовой платформой для горячего резервирования серверов, сетевого оборудования и дисковой памяти являются блейд- и флекс-системы, выпускаемые рядом производителей. Автор склонен рекомендовать подобную систему начинающим разработчикам отказоустойчивых решений (если позволяет бюджет), так как в ней производителем заранее решены многие вопросы, которые иначе могут возникнуть только с приобретением горького опыта. В то же время, горячее резервирование может быть обеспечено и путём комплексирования отдельно монтируемых компонентов. Следует отметить, что, так или иначе, необходимо решать вопрос организации централизованной системы хранения данных с альтернативным доступом для исключения единой точки отказа при выходе из строя подсистемы обращения к данным.
Устойчивость встроенного программного обеспечения к сбоям обеспечивается специальными алгоритмами прошивки UEFI и сервисных контроллеров на серверных платформах. Например, для серверов могут обеспечиваться автоматическое резервирование и восстановление прошивок аппаратуры, автоматическое резервирование загрузчика операционной системы и т.п.
Принципиально важным для обеспечения отказоустойчивости вычислительной среды является использование разного рода сторожевых таймеров, реализуемых серверными платформами. На уровне прикладных программ и кластерного программного обеспечения используется предоставляемый аппаратурой сторожевой таймер IPMI или iTCO. При загрузке операционной системы ряд серверных платформ позволяет установить собственные таймеры, контролирующие успешность этого процесса.
Однажды автору довелось наблюдать поведение блейд-сервера фирмы Lenovo, при обновлении загрузчика операционной системы на котором произошёл сбой, и файлы конфигурации загрузчика записались с ошибкой. Загрузчик начинал грузить ядро Linux, после чего зависал. Через некоторое время в сервисном процессоре сервера срабатывал таймаут загрузки ОС, и сервер перезагружался. Прошивка UEFI сервера, обнаружив, что предыдущая попытка загрузки завершилась неуспехом, самостоятельно принимала решение об откате к предыдущей версии загрузчика из архивного каталога, вызывала его, и система благополучно загружалась. Так система, которая на обычной платформе уровня рабочей станции была бы неоперабельной до ручной загрузки с ремонтного раздела, на серверной платформе благополучно автоматически загружалась в два приёма, до тех пор, пока следующим обновлением не был восстановлен правильный загрузчик. От администратора при первоначальной настройке системы требовалось только выставить корректное значение таймера загрузки.
К широко известным средствам обеспечения отказоустойчивости серверов относятся память ЕСС, объединение дисковых носителей в избыточные RAID массивы, дублирование всех компонентов серверов и серверных шасси, обеспечение альтернативных путей связи между компонентами серверной системы и пр.
Резюмируя, в настоящее время на рынке представлено достаточное разнообразие специализированных серверных систем, аппаратными возможностями которых по обеспечению отказоустойчивости не следует пренебрегать.
Напоследок, отметим распространённое заблуждение – мнение, что минимальный отказоустойчивый кластер должен состоять из трёх узлов, так как это наименьшее число, предусматривающее резервирование и при этом обеспечивающее мажоритарное голосование при выходе одного из узлов из строя. В действительности, выход из строя или перевод в обслуживание одного узла из трёх оставляет оставшиеся два узла в крайне неустойчивом состоянии взаимной конкуренции, которое с большой вероятностью может закончиться их взаимным отстрелом при малейшем сбое связи или при вводе в действие обратно третьего узла, который начнёт устанавливать с ними отношения поочерёдно. Поэтому реальная отказоустойчивая конфигурация кластера должна включать минимум 4 или 5 узлов (вероятность голосования 2:2, и сама по себе очень низкая, так как подразумевает одновременные проблемы на двух узлах, может быть исключена несимметричной топологией кластера).
4. Хостовая операционная система
Вопрос выбора хостовой операционной системы для отказоустойчивых приложений обнаруживает крайнюю зависимость от ряда привходящих моментов. К основным факторам, играющим роль в этом выборе, можно отнести следующие:
– поддержка физического оборудования;
– поддержка среды виртуализации и кластеризации;
– стоимость;
– требования по сертификации и защищённости.
Отказоустойчивые серверные платформы заявляются производителем как совместимые только с небольшим количеством операционных систем. В типичном случае, к таким системам для Intel-совместимых платформ относятся Windows, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES) и VMware ESXi. Установка других операционных систем возможна, но, как правило, приводит к отсутствию штатной поддержки критичных для обеспечения отказоустойчивости аппаратных возможностей (например, средств multipath для резервирования дисковых контроллеров).
Выбор Windows в качестве платформы для построения системы управления, по существу, означает помещение управляющих серверов в концентрированную агрессивную среду злонамеренного программного обеспечения, распространяющегося через аппаратуру неквалифицированных пользователей. С точки зрения автора, такой выбор вряд ли может быть оправдан.
Основными используемыми на сегодняшний день средствами серверной виртуализации для Unix-совместимых систем являются VMware ESXi, KVM (RHEL и SLES), Xen (SLES). Все эти платформы обеспечивают кластеризацию виртуальных машин (в качестве дополнительной опции), то есть поддержку автоматической миграции виртуальных машин с вышедшего из строя узла на резервный.
По функциональным характеристикам гипервизора, на сегодняшний день лидирующее положение занимает VMware ESXi. Однако, стоимость лицензий VMware для кластера высокой готовности, с характерным для него значительным количеством процессоров, может оказаться весьма существенной.
KVM и Xen представляют собой решения попроще и подешевле. К достоинствам KVM относится бо?льшая проработанность ряда интерфейсов виртуальных машин, к достоинствам Xen – функционирование на микроядре, что, теоретически, увеличивает надёжность работы гипервизора.
Наконец, отметим, что требования по сертификации и защищённости, действующие в отрасли, для которой предназначается разрабатываемая отказоустойчивая система, могут перечеркнуть всё вышесказанное, так как ни одна из перечисленных операционных систем может не обеспечивать выполнение требований отраслевых стандартов. В таком случае, при разработке придётся плясать от требований нормативных документов.
Окончание: часть 3
Поделиться с друзьями
amarao
Пардон, но multipath есть во всех дистрибутивах, я не понимаю при чём тут специально SLES и RHEL. Берётся ближайший дистрибутив — и там есть multipath. Из коробки.
vadimr
Ну попробуйте, например, найти multipath из коробки в какой-нибудь операционной системе, сертифицированной по российским требованиям защиты информации. Вопрос же не в том, чтобы заменить одну серверную сборку Linux на другую из эстетических соображений, а в том, чтобы приобрести этим какое-то новое свойство. К сожалению, приобретение новых свойств зачастую оказывается связанным с утратой старых.
А SLES и RHEL просто обычно тестируются производителем и указываются в списке совместимости. Как одно из следствий, под них выпускаются утилиты производителей для диагностики и настройки железа.