Hадежность без кластеризации

Кластеризация — самый очевидный способ сведения непроизводительных потерь времени к минимуму; однако можно еще больше увеличить производительность системы, если следовать приведенным ниже рекомендациям.

Компьютерный фольклор изобилует жуткими историями об ошибках системных администраторов, незамеченных особенностях системы, случаях неправильно проведенной настройки конфигурации. Иногда все эти факторы срабатывают одновременно, и результаты оказываются куда более пагубными, чем при воздействии каждого из них по отдельности; порой администратор, пытаясь устранить какую-то проблему, делает новые ошибки, и система снова простаивает. Я хочу поговорить о том, как уберечь сервер от сбоев. Правила, о которых пойдет речь, составлены на основе практического опыта, и их соблюдение позволяет существенно снизить простои — или вообще исключить их.

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

Безусловно, кластеризация — самый очевидный способ сведения непроизводительных потерь времени к минимуму и достижения высокого уровня готовности; однако можно еще больше увеличить производительность системы, следуя приведенным ниже рекомендациям. Это позволит дополнительно повысить готовность системы, сократить число сбоев и ускорить восстановление в случае, если сбой все же произойдет. Чем меньше отказов, тем реже кластер будет прибегать к средствам переключения управления с одного узла на другой. На основе этих правил можно также выявлять уязвимые места в установленной конфигурации.

Правило 1. Выберите надлежащий уровень готовности

Выбирая уровень готовности, системный администратор должен исходить из двух факторов: целесообразности и стоимости. Более высокая готовность стоит дороже. Необходимо выяснить, какой частью времени можно пожертвовать (в частности, определить допустимую частоту отказов и минимальное время восстановления после сбоя). Это позволит понять, сколько одиночных точек сбоя (single points of failure — SPOF) может быть в системе и какой уровень готовности необходим.

Определить, какие системы подлежат кластеризации, а для каких достаточно просто повысить готовность, можно, следуя приведенным ниже правилам. Вообще говоря, альтернативные средства повышения готовности применяются там, где невозможна кластеризация. Например, нельзя включать в кластер компьютеры, которые не хранят информацию о своем состоянии на диске (поскольку именно через диск передается информация о службе внутри кластера). Средства повышения готовности также используются в отношении компонентов, значение которых велико, но не является критическим. (Если система продолжает работать после сбоя компонента, последний считается важным; но если производительность резко падает, или обслуживание на время прерывается, или сбрасывается рабочее состояние какого-либо пользователя, то такой компонент является критическим.)

Правило 2. Устраните одиночные точки сбоя

Потенциальные точки сбоя имеются в большинстве систем и с трудом поддаются полному устранению. Здесь можно выделить слабые звенья, относящиеся к компьютеру (наличие только одного центрального процессора, сетевой платы и т. п.), сетевым компонентам (один сетевой кабель, один коммутатор и т. п.) и внешней инфраструктуре (один Web-сервер, один канал Internet-доступа, один разъем питания или единая энергосистема и т. д.). Общее правило таково: число одиночных точек сбоя в любой части системы должно быть сравнимо с числом подобных точек в других частях. Например, если компьютеры с нулевым числом точек сбоя подключаются к сети с большим числом таких точек, это значит, что потрачено слишком много денег на компьютерные системы и слишком мало на сетевую инфраструктуру. Необходимо решить, какой уровень устойчивости к сбоям требуется конкретному приложению, и убедиться, что этот уровень достижим во всех областях — на компьютере, в локальной сети, в инфраструктуре питания, в соединениях с глобальными сетями.

Устранение одиночных точек сбоя может оказаться непростым делом. Однако, если проследить «маршрут» данных и проверить все функциональные уровни отдельных компонентов, это позволит выявить потенциальные проблемы.

Рассмотрим, например, работу двух балансировщиков нагрузки, один из которых активный, а другой резервный. Второй активизируется только в том случае, если первый останавливается из-за сбоя. Теперь представим себе, что произойдет в случае отказа кабеля, связывающего балансировщик нагрузки и Web-сервер. Web-сервер будет по-прежнему соединен со средствами балансировки, однако рабочим соединением станет то, которое ведет к резервному балансировщику, являющемуся пассивным и не пропускающему пакеты. Следовательно, в такой конфигурации из-за простой проблемы с проводом или платой Ethernet теряется значительная часть рабочей мощности Web-серверов. Чтобы избежать этого, установите два коммутатора, которые обеспечат надежную связь каждого Web-сервера с каждым средством балансировки нагрузки.

Правило 3. Обеспечьте избыточность системы хранения данных

Для того чтобы автоматически возобновить работу после одиночного отказа диска, все запоминающие устройства должны быть организованы в дисковый массив RAID; ручное восстановление с загрузочных дисков может производиться с помощью дублирования дисков. К сожалению, RAID решает только проблемы самих дисков, но не проблемы шины, контроллера, кэш-памяти или системы питания дискового массива. В связи с этим в каждом компоненте системы хранения следует использовать два или более устройства. Зеркальные копии загрузочных дисков должны располагаться на разных устройствах и иметь раздельные источники питания, раздельные платы ввода/вывода и раздельные кабели шины. Если главной целью является минимизация простоев, следует избегать шлейфового подключения запоминающих устройств.

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

Другая проблема организации хранения данных — восстановление после сбоя диска. Попытка устранить проблему самостоятельно может привести к серьезным осложнениям. Нельзя менять диски наобум, не оповестив систему предусмотренным для этого способом. В этом случае следует внимательно изучить документацию или обратиться за помощью к производителям. Если действовать неправильно, можно лишь усугубить ситуацию.

Наконец, надо убедиться, что все запоминающие устройства (да и сами компьютеры) заземлены в соответствии с указаниями по установке. Особенно важно следить за этим в кластерах, где устройства хранения имеют двойное подключение к компьютерам. Диагностика сбоев систем хранения в таких условиях нередко указывала в качестве причины всего-навсего нарушение заземления.

Правило 4. Будьте аккуратны с исправлениями

Исправления («заплаты»), включая обновление микропрограммного обеспечения, — настоящая чума для системных администраторов: во-первых, они отнимают массу времени и сил, во-вторых, установка функции исправлений в работающей среде связана с серьезным риском. Чтобы свести этот риск к минимуму, необходимо сначала внести и протестировать исправления в тестовой среде, максимально приближенной к рабочим условиям. Например, если на практике используются серверы сети уровня предприятия, их надо установить в тестовой среде. Аналогичным образом должны совпадать типы систем хранения. В большинстве предприятий к исправлениям относятся по принципу «поставили и забыли», поэтому исправления надо устанавливать до начала рабочего процесса и обновлять только в случае возникновения проблемы.

Правило 5. Ведите постоянный мониторинг

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

Резюме

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

Диспетчер томов Veritas Volume Manager