SnapMirror, часть 1
Как-то довольно давно у меня в блоге не появлялось постов про технические фичи. Оно и понятно, блог ведется с 2007 года, и наверное уже про все в той или иной мере я уже или писал, или упоминал в предыдущие годы, сколько можно-то уже.
Тем не менее все равно остаются темы, на которые хотелось бы иметь больше информации “простым человеческим языком”, многие фичи NetApp, как я заметил, именно поэтому и не используются широко, потому что раз никто не пользуется – мало информации, а раз мало информации – вот никто и не пользуется. Так что начнем со сравнительно неплохо известного в принципе: с средства репликации SnapMirror.
SnapMirror это средство синхронной или асинхронной репликации данных как между двумя физическими системами хранения, так и для томов внутри одной системы хранения. Репликация идет по IP-сети, и в этом ее существенное отличие от других решений репликации, других вендоров, которые часто предпочитают FC.
Для начала несколько слов о том, в чем разница между двумя системами репликации, имеющимися у NetApp. Это SyncMirror и SnapMirror.
??сторически SyncMirror была синхронной репликацией (только), а SnapMirror – асинхронной (только). В те времена было все просто и понятно. Если нужна синхронная репликация – первое, асинхроная – второе. Напомню разницу: синхроная репликация – это такая, на которой сигнал “готово, записано” от стораджа к записыващему приложению не отдается до тех пор, пока блок данных не будет записан ?? на исходный сторадж, ?? на его реплику. Сперва пишем блок на локальный, потом передаем его на удаленный, записываем там, получаем ответ “записано” с удаленного, и только после этого сигналим “записано, продолжай” приложению.
- Плюсы: Мы гарантированно имеем два стораджа в синхронной, идентичной копии. Если блок не записан на удаленную систему, то и на локальной он не записан, и приложение об этом знает. Никакой потери данных и рассинхронизации из-за обрыва связи между стораджами нет “по определению”. Это самый надежный способ.
- Минусы: Это, одновременно, и самый медленный способ с точки зрения приложения. Нетрудно видеть, что скорость работы с приложением, bandwidth между приложением и стораджем, равен скорости работы, bandwidth между локальным и удаленным стораджем. Если у вас приложение подключено к стораджу по 8Gb FC, а канал между стораджами, находящимися в синхронной репликации, составляет 10Mb/s, то максимальная скорость передачи данных между приложением и локально подключенным по FC 8Gb стораджем будет составлять не более 10 мегабит в секунду, то есть будет равным скорости межстораджевого канала репликации.
Отсюда видно, почему синхронная репликация крайне редко применяется в “географически” разнесенных решениях, а там, где она применяется в таких решениях, например в NetApp Metrocluster, это сложная и дорогая конструкция, с отдельной “фабрикой” репликации, занятой только этим.
Гораздо чаще на практике для репликации двух систем хранения используют так называемую “асинхронную” репликацию. В этом случае локальная система сразу сигналит “записано” приложению, а потом, с определенным интервалом, шлет обновления на удаленную систему – “Эй, тут у меня есть свежак, прими!”
- Плюсы: Производительность работы приложения с локальным стораджем максимальна, канал репликации не ограничивает производительность приложения. Кроме того существенно экономится и ресурсы самого канала. Представим себе, что приложение каждые несколько миллисекунд изменияет один блок данных. В случае синхронной репликации, каждое такое изменение должно быть передано на удаленную систему. А в случае асинхронной репликации – только одно, состояние этого блока на момент начала репликации, или же итоговое его значение после всех изменений.
- Минусы: Удаленная копия никогда не становится идентичной локальной. Она ее всегда догоняет, но, если изменения непрерывны, всегда отстает, и этот интервал отставания называется “лагом репликации”. Более того, если не предпринимать специальных мер, то приложение может и не узнать, что каких-то данных на удаленной системе нет, или они не соответствуют данным локальной системы.
Некоторым промежуточным вариантом является так называемая “полусинхронная” или “квазисинхронная” репликация, то есть пока успеваем физически – синхронная, когда не успеваем – не тормозим локальную систему, а переходим в асинхронный режим, и синхронизируемся так, пока не догоним, после чего опять переходим в “синхрон”.
Так вот, в свете всего вышеизложенного, SyncMirror это в чистом виде синхронная репликация, причем на достаточно низком уровне. Так как вы помните, что в NetApp его RAID это просто то, как функционирует его файловая система WAFL, можно считать, что SyncMirror это просто в этой файловой системе функция RAID-1, “зеркалирование”, “мирроринг”, или, вернее будет, RAID-41 или RAID-61, как принято называть комбинированные уровни, одни, поверх уже имеющихся других.
На сегодня SyncMirror в ее изначальной форме широко применяется только в Metrocluster.
SnapMirror – это дело другое. Она изначально создавалась как асинхронная репликация на сравнительно “высоком” уровне дисковых абстракций. Однако впоследствии удалось к ней добавить синхронный и полусинхронный режим работы, и сегодня вы можете выбирать нужный вам режим просто указывая нужный ключ в настройках в конфиге.
Обратите внимание также, что в текущей лицензионной модели SyncMirror бесплатно входит в Data ONTAP Essentials, то есть присутствует бесплатно на любой системе хранения, а вот SnapMirror стоит денег, причем довольно существенных, и это отдельная лицензия.
Ну и, наконец, слово Snap в названии как бы намекает нам, что за технология использована при реализации репликации – это снэпшоты, или разностные “снимки состояния” соответствующего тома. При организации репликации сначала осуществляется так называемый baseline transfer, то есть передача исходного состояния. Это довольно продолжительная и емкая по ресурсам задача, когда целиком весь объем данных реплицируемого тома передается с локальной на удаленную систему. Зато потом, когда завершен baseline transfer на удаленную систему по каналу репликации передаются только изменения от одного цикла репликации до другого, они, обычно, сравнительно невелики по объему. Технически сторадж для этого делает специальный служебный, обычно невидимый пользователю снэпшот с реплицируемого тома, а затем получившиеся изменения передает на удаленную систему, “накатывая” их на тот том, находящийся в специальном состоянии restricted, после чего служебный снэпшот удаляется, на следующий цикл обновления операция повторяется.
??так, разобравшись с тем, что является, и что не является SnapMirror, перейдем к деталям. Продолжение следует.
SnapMirror, Часть 2.
Пять копеек про syncMirror - сейчас nettapp позиционирует эту технологию, как средство от отказа полки (говорят, такое тоже бывает). В сопутствующих плюшках - повышение скорости чтения на 80% и значительное повышение устойчивости рейда при отказе больших дисков, особенно под нагрузкой.
panvartan:
Ну это не прям вот сейчас, а уже несколько лет как, насколько я помню, ну и - да, возможность параллельно читать с зеркала действительно позволяет улучшить производительность чтения, как и для всех ныне существующих RAID-1 контроллеров.
Мне вот интересно как сохраняется консистентность данных при асинхронной репликации. Если механизм базируется на снапшотах, которые могут быть консистентными при использовании снапменеджеров. Собственно вопрос - как? (возможно я что-то не понимаю)
Александр,
В случае установленных “отношений” SnapMirror между массивами можно отдавать команду на апдейт удаленной копии средствами нужного SnapManager.
Проще говоря, SnapManager делает консистентный снапшот тома, после чего именно этот снапшот передается на удаленную систему.
Если я правильно помню, репликация идет по IP, но при этом есть возможность в качестве транспорта использовать Fibre Channel (IP over FC).
Артур:
Да, но для этого обязательно использовать специальную интерфейсную плату, через который будет идти такая репликация, в общем в живой природе я ни разу такого варианта не видел, это осталось в качестве поддержки какого-то глубокого легаси в прошлом веке.