Metrocluster (part 2)
Как мы уже рассматривали выше, межкластерное соединение по длине ограничено возможностями канала Infiniband, по которому осуществляется взаимный согласованный доступ между узлами, и его физическими характеристиками. Таким образом нам доступна дистанция разноса узлов кластера в 30 метров без каких-либо дополнительных средств. Что же, если мы хотим создать кластерную систему, разнесенную для катастрофоустойчивости на значительно большее расстоняие?
Для этого создана система, под названием «Metrocluster».
Давайте рассмотрим подробнее из чего она состоит, что дает по сравнению со стандартным кластером NetApp, и как работает.
Одной из проблем, которую вынуждена решать кластерная система любого производителя, есть проблема «split brain». Это ситуация, когда, в результате разрыва соединения между кластерами, оба узла кластера считают себя выжившими, а партнера – мертвым. ?? пытаются взаимно перехватить ресурсы соседа. В ряде случаев им это удается, и мы получаем в результате две несинхронизированных и различных копии данных, одну на дисках, подключенных к одному узлу, другую – к другому, оба продолжавших работать.
Кроме того, констроллер узла может потерять связь разным способом, не только межкластерную связь, но также и связь с дисками, причем также и одновременно и то и то. Логика кластерного монитора должна правильно обрабатывать такие ситуации и находить решения для продолжения работы и восстановленя доступности ресурсов.
Для разрешения этих проблем, каждая «голова» кластера владеет группой «своих» дисков, а также зеркальной копией дисков соседа. ??, соответственно, сосед также.
А тут я хочу напомнить, что в настоящее время NetApp имеет две версии своего ПО для контороллеров, «классическая» линейка, в настоящее время носящая номер 7, и новая, версия X, которая пока еще не имеет всего богатства функционала «классической» версии, однако в отличие от «классика», ограниченного всего двумя узлами в кластере, позволяет строить grid-кластеры с количеством узлов до 24. В скором времени ожидается полное слияние «традиционной» и «новой» версии как по функционалу, так и по поддержке платформ, таким образом пользователи систем NetApp смогут строить многоузловые распределенные кластерные системы хранения.
Это дает кластеру возможность правильно обрабатывать любую ситуацию и гарантирует сохранность и доступность данных при любой возможной ситуации сбоя: отказ дисков, отказ контроллеров доступа, отказ соединительных линий и междисковых путей данных.
Метрокластер есть по сути комбинация из опции Local SyncMirror, опции синхронной репликации, «зеркала» данных, и опции кластера системы NetApp.
Метрокластер может существовать в варианте Stretched Metrocluster, то есть «растянутого», при этом, для расстояний до 300 метров, используется специальный оптический кабель и конвертеры «медного» Infiniband в оптический канал. Обычно это довольно ограниченный по своим возможностям вариант, но в ряде случаев он выбирается, если нет смысла городить полноценный огород ради разноса узлов системы на 200 метров.
Второй вариант принято называть Switched Metrocluster. При этом создается специальная выделенная «фабрика» для дисков системы с помощью FC-коммутаторов партнера NetApp, компании Brocade (в настоящее время используются коммутаторы Brocade 200E с лицензией Full Fabric). В качестве канала данных между двумя половинами «фабрики» используется 4GB Longwave FC optics с соответствующими трансиверами. Дальность «разноса» узлов кластера в конфигурации Switched Metrocluster может достигать 10 км - расстояния, доступного для Longwave FC. Дальнейшее его увеличение приводит к увеличению задержек и «пологости» фронтов сигналов вследствие конечности скорости света в оптоволокне, что и является, в данном случае, ограничением.
Необходимость же жестко выдерживать временные скоростные характеристики следует из самой логики, принципа работы. Ведь весь «метрокластер», как структура, представляет из себя не просто логически единую структуру, но и физически в значительной степени однородную.
Это позволяет рассматривать данные, размещенные на устройстве Metrocluster как не только отказоустойчивые, но и совершенно прозрачно для приложений и использующих их «потребителей» распределенные, с точки зрения как просто распределенный «жесткий диск». В этом и заключается основное отличие и преимущество перед решениями иных производителей систем хранения, которые предлагают либо локальный, «катастрофонеустойчивый» кластер, либо распределенную синхронную или асинхронную, более или менее непрозрачно действующую для приложений пользователя.
Дальнейшее увеличение «распределенности» для систем хранения NetApp обычно достигается при помощи репликаций различного вида, впрочем об этом, и о предложении NetApp в этой области мы уже говорили ранее.
Подробнее по теме:
TR-3548: MetroCluster Design & Implementation Guide
TR-3517: MetroCluster Upgrade Planning Guide
TR-3606: High Availability and Disaster Recovery for VMware Using NetApp SnapMirror and MetroCluster