Метрокластер (metrocluster) - это кластеризованная, распределенная (metro - metropolitan) система хранения, разработанная NetApp на базе своих систем хранения среднего и верхнего класса. Она позволяет строить катастрофоустойчивые решения по хранению данных, и характеризуется поразительной простотой в эксплуатации. В значительной мере это решение уникально по множеству параметров среди всего, предлагаемого сегодня рынку производителями систем хранения данных.
Для того, чтобы рассказать о конструкции «метрокластера» - концептуальном нетапповском распределенном «кластере хранения» необходимо прежде всего подробнее рассказать о реализации кластера в системах NetApp вообще, поскольку «metrocluster» в значительной мере базируется на этих концепциях, а они, в значительной мере, уникальны для сегоднящних систем хранения на рынке.
“Спецпредложение! Клиент, заплативший двойную цену, второй экземпляр получает бесплатно!”
Мы привыкли к системам без единой точки отказа, так называемым «fault tolerance» системам. Как правило такая конструкция подразумевает дублирование всех критически важных узлов, таких, как блока питания, контроллера управления (на каждом процессор и кэш-память), предусматривается два пути доступа к данным, с тем, чтобы обрыв одного из проводов от сервера или FC-фабрики не прекращал доступа к данным. В общем всего по два, на всякий случай, за исключением собственно корпуса системы хранения. Ну и конечно диски, чаще всего в RAID0+1, что по сути означает то же дублирование. Довольно простое и безыскусное решение. Впрочем весьма действенное. А с тем, что мы по сути платим за две системы, в то время, как пользуемся одной, приходится мириться. Надежность хранения данных, как правило, это вещь, стоящая этих денег.
Однако дублирование всего, за исключением корпуса, то есть «физической сущности» системы хранения, спасет наши данные в случае отказа любого из элементов внутри системы хранения, и, частично, инфраструктуры (те самые «два пути доступа к данным»). Но не спасет, если проблема будет извне.
Общий отказ электропитания здания (обоих линий), пожар или наводнение, даже если это будет «наводнение» из лопнувшей трубы отопления или водопровода. Такая пошлая и банальная причина ничуть не делает катастрофу менее катастрофической по последствиям. Ну разве что в газеты вы не попадете, но станет ли вам легче, если причина пожара или наводнения будет не у вас, а, например, у соседа по зданию?
Сейчас я даже не касаюсь такого специфического «русского дизастера», как приезд более или менее компетентных органов, и изьятия оборудования для обеспеченя «оперативно-разыскной деятельности» впредь до особого уведомления, что, по катастрофическим последствиям своим, думаю, сравнимо с самыми серьезными форс-мажорами цивилизованных стран.
Как правило для борьбы с такими несчастьями используются решения, называемые «катастрофоустойчивыми» или «disaster recovery solutions».
Обычно они подразумевают размещение двух идентичных систем хранения (каждая из них, если вы помните, в «двойном экземпляре» для защиты от внутренних отказов оборудования) в различных помещениях, возможно в разных зданиях или даже в различных городах или странах.
С помощью системы репликации данных, доступных ныне даже для систем хранения начального уровня, данные с рабочей системы реплицируются на удаленную. Да, но что же дальше?
Вопреки распространенному мнению, репликация на вторичную систему вовсе не делает «решения». Вы так или иначе конечно получаете реплику ваших данных, но нужно предпринять ряд усилий, чтобы остановить репликацию, смонтировать реплики в правильном порядке на сервера, а по окончании неприятностей вернуть все в исходное состояние.
Каждым производителем систем предлагаются какие-то решения, ка правило с помощью дополнительного ПО, но нигде это не является простым и, на практике, беспроблемным.
Когда задачей создания отказоустойчивой системы хранения столкнулись инженеры компании NetApp, у них сразу возникла мысль решить эту задачу иным, нежели привычный, способом.
Поскольку концептуальным свойством систем NetApp является простота эксплуатации, то отчего бы не сделать отказоустойчивую систему в виде кластерной системы, причем сделать весь «отказоустойчивый» функционал полностью прозрачным на уровне «пользвателя»-сервера?
При этом кластерная система не просто позволяет достичь отказоустойчивости, как в рассмотренной выше fault tolerance схеме «всего по два», но и с легкостью получить катастрофоустойчивость, путем разнесения узлов кластера, ведь эти узлы полностью независимы физически.
Так появился традиционный «кластер» NetApp, подавляющее большинство систем сейчас продается в такой конфигурации. Два блока контроллеров, каждый в своем корпусе, каждый полностью автономен, соединены между собой высокоскоростным каналом на базе протокола Infiniband. Этот канал (физически – два кабеля, два независимых канала) позволяет в штатной поставке разнести два контроллера, или в прижившемся термине самого NetApp, две «головы» (head), на расстояние до 5 метров, а с использованием дополительно заказываемого, более длинного кабеля – до 30 метров. Это еще не полноценная катастрофоустойчивость, но уже кое-что, как, например, возможность разнести две части системы хранения по двум соседним помещениям в здании.
Как это выглядит с точки зрения пользователя?
Пользователь (здесь и далее под «пользователь» понимается не столько юзер на компьютером, сколько «пользователь данных системы хранения» - сервер) видит две виртуально независимых системы хранения, каждая голова обрабатывает свою часть данных, своеобразный режим Active-Active, в отличие от, например, Active-Passive, когда из двух контороллеров, один работает, а сторой стоит и ждет, когда первый сломается, но интересное начинается в момент, когда по какой-то причине работа одной из «голов» системы прекращается. Диски подключены по двум независимым путям, одним к одному контноллеру, вторым к другому, но «владелец» той или иной группы дисков только один, она «приписана» к той или иной «голове». В случае отказа штатного владельца группы дисков, «выжившая» голова перехватывает «чужие» диски, такое делают все системы хранения в fault tolerant-конфигурации, однако для систем NetApp это еще не все. Живая голова переносит на себя ресурсы, обслуживавшиеся недоступной ныне «головой», такие как имена shares, имена ресурсов и IP-адреса в случае NAS, а также WWN FC-портов и LUNы, в случае работы в SAN. С точки зрения «пользователя» данных все это происходит совершенно прозрачно, никаких перенастроек на стороне серверов делать не нужно. Просто через короткое время все используеые ресурсы, размещенные на вышедшей из строя части системы хранения, вновь оказываются работоспособными.
«Жесткий диск» в сети SAN, или как NAS-устройство остается живой независимо от происходящих с системой в целом происшествий. Естественно это не чудо, и если одна из «голов» работает на пределе своей загрузки, то, в случае «подхвата» ей ресурсов партнера, и с ними дополнительной загрузки, возможно падение общей производительности. Однако, на практике, «прозрачность» доступности пользовательских данных, когда данные доступны без дополнительной перенастройки, пусть и не так шустро как раньше, это значит гораздо больше.
Дальше - больше…
Запись опубликована about NetApp.Пожалуйста, оставляйте коментарии там.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
