Такие природные явления, как цунами, сильные землетрясения, извержения вулканов или экстремальные наводнения, случаются редко, но и крупные пожары, повреждения линий или сбои в подаче электроэнергии могут полностью парализовать работу центров обработки данных.
Высокая доступность всегда достигалась путем обеспечения избыточности — это актуально и в случае подготовки к экстремальным ситуациям, когда весь ЦОД необходимо защитить от сбоев в подаче электроэнергии или от природных катастроф. Если один из ЦОД выходит из строя, территориально разнесенный кластер автоматически и без прерывания рабочих процессов переключается на второй, а при необходимости и на третий центр обработки данных. По сути, это не что иное, как локальный кластер, разнесенный между двумя или тремя площадками, с локально зеркалированной системой хранения.
В соответствии с концепцией территориально разнесенных кластеров на каждой площадке должен быть отдельный уровень хранения, который, в свою очередь, отвечает принципу обеспечения высокой доступности, то есть представляет собой кластер с двумя узлами (Node). Этот кластер предоставляет дисковое пространство для сервисных узлов (Service Node). Последние зеркалируют имеющиеся данные между двумя площадками, а вместе четыре узла формируют один территориально распределенный четырехузловой кластер (см. Рисунок 1).
.png "Рисунок 1. Схематичное изображение структуры территориально распределенного кластера с двумя площадками.") |
| Рисунок 1. Схематичное изображение структуры территориально распределенного кластера с двумя площадками. |
Территориально распределенные кластеры могут быть организованы таким образом, что в них не останется критических точек отказа (Single Point of Failure). Таким образом, сбой в работе аппаратного обеспечения — неважно, на каком уровне — не потребует переключаться между площадками вручную: большое преимущество таких решений заключается в том, что при возникновении проблемы переключение происходит совершенно прозрачно и без какого-либо вмешательства администратора. Если бы при этом использовалась только технология асинхронной репликации данных, то решение о принятии аварийных мер все равно пришлось бы принимать человеку, что привело бы к значительным задержкам. Кроме того, потребовалось бы наличие плана действий на случай чрезвычайной ситуации, в котором четко указывалось бы, как и когда необходимо осуществлять переключение. Автоматизация этого процесса гарантирует непрерывную работу всех приложений.
Помимо защиты данных предприятия, территориальная распределенность кластеров имеет еще одно важное преимущество: метрокластеры не нужно останавливать, чтобы обновить их аппаратное или программное обеспечение. К тому же они весьма просты в реализации и последующей эксплуатации. Правда, соединения между площадками должны иметь очень низкие показатели задержек (Latency), так как большие задержки отрицательно сказываются на производительности всей системы. А поскольку с увеличением расстояния задержки увеличиваются, расстояние между ЦОД не должно превышать 50 км.
Таким образом, метрокластеры выгодны тем предприятиям, которые либо занимают очень большую территорию, либо имеют филиалы, отстоящие один от другого не более чем на 50 км. По этой причине в США эта концепция не получила широкого распространения, ведь в большинстве случаев расстояния между филиалами компаний там гораздо больше, а значит, о метрокластерах не может быть и речи. Во всех других случаях компании смогут при малых инвестициях поднять доступность своих систем на новый, ранее недостижимый уровень.
СЦЕНАРИИ СИСТЕМНОГО СБОЯ
У каждого территориально распределенного кластера множество слабых мест, способных парализовать работу системы. Поэтому главная задача заключается в том, чтобы для каждого из возможных случаев предоставить автоматические резервные решения, позволяющие предотвратить сбои в работе приложений. Рассмотрим семь сценариев отказа систем и возможных последствий на примере метрокластера, созданного на основе файловой системы ZFS компании Sun (она используется, к примеру, в решении Nexentastor, предлагаемом Nexenta Systems).
- Отказ жесткого диска. В этом случае обычно никаких отрицательных последствий для дальнейшей работы систем не бывает. Администратор может заменить поврежденный диск в «горячем» режиме, после чего данные снова автоматически синхронизируются.
- Выход из строя важных компонентов дисковых полок (Disk Shelves). При отказе кабеля SAS (Serial Attached SCSI), адаптера главной шины SAS-HBA (Host Bus Adapter) или расширителя SAS (SAS Expander) технология множественного доступа (Multi-Pathing) в узлах хранения (Storage Node) обеспечит непрерывную работу всех сервисов. И в этом случае администратор может провести оперативную замену неисправных элементов.
- Сбой в работе всей дисковой полки. Массивы жестких дисков RAID-Z2 распределяются по системам с простым последовательным подключением дисков (Just a Bunch of Discs, JBOD) таким образом, что даже полный отказ одной JBOD-системы можно пережить без потерь. Когда такая система возобновит работу, синхронизированы будут только те данные, которые претерпели изменения до этого момента. Таким образом, все сервисы продолжат функционировать без простоев и значительных спадов производительности не будет.
- Нарушения в работе узла хранения. При отказе всего сервера узла хранения его обязанности в течение нескольких секунд переходят ко второму серверу, расположенному на той же самой площадке. Происходящее в этом случае кратковременное прерывание потока ввода-вывода данных будет замечено вышестоящими сервисными узлами, но не скажется на работе приложений, поскольку в каждый момент времени производится зеркалирование данных на вторую площадку.
- Проблемы в работе коммутатора, кабеля или HBA-адаптера Fibre Channel между узлами хранения и вышестоящими сервисными узлами. Технология множественного доступа на сервисных узлах позволяет справиться и с этим сценарием. Резервного переключения на второй ЦОД не потребуется, и конечный пользователь не ощутит никакого снижения производительности приложений.
- Неработоспособность?сервисного узла. В случае отказа всего сервисного узла при использовании файловой системы ZFS происходит кратковременное — длительностью в несколько секунд — прерывание потоков ввода-вывода данных к приложениям и от них. Время переключения определяется количеством используемых сервисов, таких как NFS Share, CIFS Share или iSCSI Target, и не зависит от объемов данных. Одна из особенностей технологии ZFS, отличающая ее от других файловых систем и систем хранения, заключается в том, что ей никогда не требуется проведение полной проверки файловой системы. Для серверов приложений это переключение прозрачно; а если применяется Fibre Channel, им необходимо получить у операционной системы драйвер Multi-Path с поддержкой асимметричного доступа к логическим элементам (Asymmetric Logical Unit Access, ALUA), что во многих случаях является стандартной функцией. При этом кластеры настроены таким образом, что в случае сбоев сервисы сначала переносятся на соседние узлы и необходимость в переключении на территориально удаленный узел возникает, только если работа филиала нарушается полностью.
- Недоступность всей площадки. В самом худшем варианте возможен сбой в работе филиала в целом. Только в этой ситуации территориально разнесенный кластер использует избыточность на уровне ЦОД для преодоления сбоя и системы, находящиеся на второй площадке, берут на себя поддержку всех сервисов. Таким образом, серверы приложений сохраняют доступ ко всем службам, пусть и с половиной сервисных узлов, то есть с ограниченной производительностью. Поскольку при таком сценарии зеркалирование, считывание и запись данных между территориально разнесенными филиалами не производятся, длительность задержек сокращается. При работе, к примеру, с базами данных их производительность нередко даже улучшается. Когда площадка, на которой произошел сбой, снова войдет в рабочий режим, благодаря файловой системе ZFS осуществлять обратное зеркалирование всех файлов не придется. Передать потребуется только те данные, которые были изменены за время простоя, поэтому после устранения локальных проблем пострадавший ЦОД сможет очень быстро вернуться к нормальной работе.
Хайко Вюст — инженер по продажам в компании Nexanta Systems.