Archive for the ‘techtalk’ Category.

Reallocation в Data ONTAP. Часть 1.

Многие мои посты тут пишутся заранее, и потом отлеживаются. Некоторые – отлеживаются в моей голове. Но среди них есть порой и настоящие старожилы, вот, например, посту на тему того, как работает reallocation в WAFL и Data ONTAP, скоро уж три года. Все это время я пытаюсь сложить полноценную, непротиворечивую и исчерпывающую картину вопроса, чтобы изложить это все в блоге. Проблема в том, что, вследствие закрытости многих механизмов работы Data ONTAP (а также того, что они меняются, а закрытость позволяет не рассказывать публике об изменениях в деталях), многие вопросы остаются для меня не исчерпывающе отвеченными. Но, тем не менее, давайте перестанем тянуть кота за хвост, и приступим к тому, что нам известно, и о чем можно рассказать.

Тема процесса перекомпоновки блоков данных в структурах WAFL всегда была темноватой, и, как любая тема, испытывающая недостаток ясности, она раз за разом становится поводом для более или менее честных спекуляций, причем не только со стороны конкурентов NetApp по рынку систем хранения данных, но, зачастую, и среди самих пользователей. Типичным ходом в такой спекуляции является назвать процессы записи на WAFL – “фрагментацией”, и, готово дело, дальше уже можно пугать потенциальных клиентов NetApp жупелом, растущим еще из FAT и обязательного Norton Defragment с бегающими квадратиками.

О том, насколько на самом деле так называемая “фрагментация” на WAFL влияет на производительность я уже писал не раз, не стану повторяться, все есть по ссылкам выше, сегодня поговорим об обратном процессе, что же представляет собой процесс reallocation.

Reallocation – это фоновый процесс в OS Data ONTAP, который оптимизирует и перераспределяет структуру хранения блоков WAFL для оптимизации к ним доступа. Он близко связан с тем, как именно происходит запись данных на WAFL в OS Data ONTAP. Не вполне корректно называть процесс реаллокации - “дефрагментацией”, как и проводить аналогии с файловой системой, например FAT, построенной на совсем иных  принципах выделения пространства. Многие годы считалось, например, что файловые системы Linux (читай inode-овые BSD-like файловые системы, с использованием идей которых создана и WAFL) вообще не подвержены фрагментации, так, до ext4 там вообще не существовало штатных средств “дефрагментации”, и ничего, работали же, а многие системы в продакшне и на ext3fs работают и до сих пор. Но, конечно, фрагментация, или, корректнее non-contiguous file allocation существует и в них, и с ростом дисковой нагрузки на серверные системы в целом, и увеличении объемов хранения, несомненно эта проблема стала все более заметной. Оставим сейчас в стороне спор, насколько фрагментация данных влияет в условиях, когда практически 100% workload составляет не sequental, а random access, об этом я уже писал, поговорим о том, что же можно сделать для оптимизации структуры хранения путем вот этой самой block reallocation. Подобной “фрагментации” данных подверженны все системы хранения (особенно использующие современные фишечки работы с данныеми, такие как снэпшоты, дисковые пулы, thin provisioning, а не просто dumb SCSI LUN). Но не все умеют с этим бороться.
NetApp – умеет.

В документации сказано скупо:

reallocate - Command for managing reallocation of files, LUNs, volumes, and aggregates

The reallocate family of commands manages the allocation, or layout optimization, of large files and
LUNs on a node. Additionally all files in a volume may be reallocated, and the block layout of
aggregates may be optimized. Using the reallocate command, layout measurement and optimization
(reallocation) can be automated.

Определенную сложность для пользователей вызывает тот факт, что процесс reallocate не запущен на системе по умолчанию. Сделано это, по всей видимости, исходя из главного принципа, которым руководствуется NetApp, назначая свои значения по умолчанию. Даже если вы не прочтете ни одной страницы документации, и запустите систему хранения “энтером” (то есть просто тупо давя Enter на все вопросы, соглашаясь на все установки по умолчанию), то даже при сочетании самых нелепых решений, данные не будут повреждены и система будет, пусть неоптимально, но работать. В общем тот самый врачебный Noli Nocere! - “Не навреди!”. Реаллокация может быть не нужна в ряде профилей использования. Но даже когда она не нужна, а она запущена по умолчанию, и при этом вы об этом не знаете, она неизбежно занимает какую-то долю системных ресурсов, и лучше было бы, чтобы, если уж она запущена, то запущена она была “по делу”, и понимающим это человеком.

Вот поэтому по умолчанию, на свежеустановленной системе процесс reallocation не запущен автоматически и не работает.

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

  1. Насколько сильно, в процентном отношении, заполнены активными, изменяющимися, а не просто хранящимися данными, заполнены диски, конкретнее - тома на aggregate?
  2. Каков процент свободного места на томах и aggregate? (помните, что WAFL – структура thin by design, и для нее 100% занятый пустыми томами aggregate – пустой)
  3. Насколько активно используется на томах deduplication, и сколько места она у вас высвобождает.
  4. Наконец, насколько часто вы расширяли тома и aggregate физическими дисками?

На первые два вопроса ответ, и то как он соотносится с темой необходимости реаллокации, вы, скорее всего уже знаете. Если на диске в момент записи достаточно свободного места, то подсистема, выделяющая на диске место по запросу OS в форме дисковых экстентов, или протяженных сегментов блоков, с легкостью найдет и выделит процессу записи любое нужное количество блоков в единой цепочке. Именно по этой причине в таких файловых системах, как ext2/3 и NTFS фрагментация файлов в самом деле принципиально ниже, чем в FAT, где OS не использует такое “групповое выделение” блоков, и занимает их по порядку, один за одним, не обращая внимание на то, где и как они расположены. Разумеется такой вариант, особенно в активной и, как это называется, aged, то есть давно используемой в работе файловой системе, вызывает существенное дробление фрагментов файла по диску.

Это не так в уже перечисленных “BSD-like” системах и NTFS. Пока на файловой системе есть достаточно свободного места, механизм выделения цепочек последовательных блоков работает хорошо. Сложности начинаются тогда, когда файловая система заполняется файлами, которые произвольно создаются и удаляются, и постепенно структура блоков данных начинает напоминать сыр с его дырками, когда вроде место и есть, но оно все “пузырьками”. Дело в том, что если последовательный экстент блоков нужной длины на дисковом томе найти не удается (а данные писать все ж таки надо), то описываемая подсистема OS говорит файловой системе: “ну ОК, давай мне два покороче, пусть в разных местах. Нету? Ну что-ж, ну а четыре еще короче есть?”. И такое дробление продолжается до тех пор, пока вся последовательность, ожидающая записи на диски не будет записана.

Очевидно, что чем меньше у файловой системы будет “пространства для маневра”, то есть последовательно свободного пространства на томе, и чем больше будет на этот том записей и перезаписей, тем сложнее ей будет  с каждым разом  находить связные последовательно куски блоков. Именно по этой причине, например, Windows тревожно закрашивает красным диск, слишком сильно заполненным данными. Если это диск с файловой системой, которая не просто залита фильмами, как на скриншоте ниже, а активно обновляется, записывается и перезаписывается данными, то вскоре вы увидите, что коэффициент фрагментации файлов, ранее невысокий, на ней вдруг начнет резко расти, ухудшая ее характеристики производительности.

image

Напомню, что рекомендуется поддерживать 10-15% свободного места на томе и aggregate для нормальной работы описанных выше механизмов (это примерно совпадает с рекомендациями MS для NTFS), причем на уровне aggregate это пространство уже зарезервировано в WAFL reserve, недоступном пользователю.

Подводя итоги по этой части хочу специально указать: это рекомендация, но не требование. Вы МОЖЕТЕ заполнить диск данными на все 100% его емкости. И в ряде случаев, например как на картинке выше, где приведен скриншот моего лэптопа, и где выделенный диск есть хранилище бэкапов, фильмов и музыки, то есть записи на него нерандомны и крайне редки, это не имеет большого значения и мало влияет на его производительность.

Но если ваши данные активно перезаписываются, и у вас есть возможность не заливать их на том “с горкой”, то оставьте побольше свободного места на томе (и на aggregate для thin-томов) – не пожалеете :)

Итак, чтобы не раздувать один пост, продолжим на следующей неделе.

Новые версии SnapDrive Win 7.0, SnapManager for SQL 7.0 и Hyper-V 2.0

Тем временем, на прошлй неделе NetApp обновил несколько своих важных утилит “стороны хоста”. Как вы знаете, и многие, уверен, пользуетесь, средствами работы со стораджем на стороне хост-системы. С выходом Server 2012 и 2012 R2, и их новых возможностей, насущно встала необходимость обновления набора хост-инструментов NetApp.

Появилась новая версия SnapDrive, инструмента для создания снэпшотов, LUN-ов и управления ими со стороны сервера. Также этот инструмент предоставляет API для работы многим другим программным хост-средствам NetApp.

Основные новинки это:

  • Поддержка Cluster-mode (наконец-то)
  • Поддержка SMB 3.0
  • Sub-LUN cloning
  • Поддержка командлетов PowerShell 2.0+ для SMB 3.0
  • Virtual Fibre Channel
  • Поддержка gMSA – group Managed Service Account в Windows Server 2012

Опубликован TR-4000: "SnapDrive 7.0 for Windows Best Practices for Clustered Data ONTAP".

SnapManager for Hyper-V обновился до долгожданной версии 2.0

Среди новинок:

  • Интеграция со SnapVault
  • Поддержка не только SAN (FC, iSCSI, FCoE), но и SMB 3.0, в частности теперь поддерживается remote VSS hardware providers
  • Для SMB 3.0 и CSV 2.0 также поддерживаются SnapInfo
  • Поддерживаются gMSA
  • Наконец-то поддерживается восстановление по альтернативному пути (например для DR-сайтов) и восстановление удаленных (deleted) VM из бэкапов типа crash-consistent.
  • Поддерживается установка на remote-хост.

Вместе со всеми обновился и третий важный компонент win-хост инструментов: SnapManager for SQL Server.

Новинки:

  • Поддержка SMB 3.0 (напомню, что пока SMB 3.0 есть только на Cluster-mode!)
  • Интеграция со SnapVault (archived backup могут отправляться на secondary SnapVault на clustered-системе)
  • Восстановление базы данных в другое расположение того же инстанса MS SQL Server
  • Поддержка gMSA и возможность запуска SMSQL из него
  • Улучшена производительность работы для ряда сценариев использования

Все версии опубликованы и доступны пользователям NetApp для скачивания на сайте NetApp Support.

Не забывайте внимательно читать Release Notes перед установкой или обновлением!

Что HP думает о NetApp, и как все обстоит на самом деле. Часть 2

 

Природа не терпит пустоты: там, где люди не знают правды, они заполняют пробелы домыслом.
Джордж Бернард Шоу

В прошлом посте я начал детальный разбор довольно объемного текста, написанного специалистами компании HP о том, как и в чем они видят недостатки систем хранения NetApp. Так как с их стороны это оказалось крайне субъективное и неточное изложение вопроса, грешащее многочисленными ляпами, более или менее неосознанными заблуждениями и непониманием ряда основополагающих технологий, использованных у NetApp, я счел себя обязанным не оставлять его без ответа, и написать эту комментрованную рецензию, которую и предлагаю вашему вниманию. Это – вторая половина текста, смотрите первую часть в предыдущем посте.

Я намеренно выбрал тут тактику “чистой обороны”, и ничего, или почти ничего не говорю о свойствах и недостатках систем “противной стороны”, хотя, безусловно, у NetApp есть что острого и ехидного спросить у HP на их счет. Я лично считаю жанр “говнилок”, в котором написан исследуемый текст, довольно-таки “грязным”, он пишется, как правило, анонимно, и, по законам жанра, изобилует полемическим передергиванием, лично я считаю, что писать такие тексты – западло (давайте я уже скажу это слово ;). Но – “с волками жить – по волчьи выть, иначе будешь сидеть без бонусов”, я понимаю что именно заставляет такое писать.

А теперь давайте продолжим разбор обсуждаемого документа.

Continue reading ‘Что HP думает о NetApp, и как все обстоит на самом деле. Часть 2’ »

Что HP думает о NetApp, и как все обстоит на самом деле. Часть 1

 

Пару недель назад мне в руки попал текст, подготовленный специалистами компании HP, продававшей систему HP 3Par, или как она сейчас называется, StoreServ 7000 против предложенного уже этому клиенту midrange NetApp. Документ относится к популярному в российском IT жанру “говнилок”, или, выражаясь интеллигентно – FUD (Fear, Uncertainity and Doubt). Как правило такие документы мне приходится встречать со стороны пресейл-инженеров компании EMC, но впервые мне попадается в полном виде текст от HP, этим он особенно интересен. HP, как компания, находится в довольно-таки привелигированном положении на рынке, в особенности на российском. Это большая, крайне авторитетная компания “полного стека”, которая может предложить своим клиентам полный спектр оборудования, от серверов и систем хранения, активное сетевое оборудование, до шкафов и UPS.

Тем печальнее, что за последних 10 лет отдел систем хранения в компании был в явном “загоне”. Обладая в начале 90-х передовой и в чем-то даже революционной системой хранения EVA (Enterprise Virtual Array), компания “почивала на лаврах” и допочивалась до того, что EVA на рынке катастрофически морально устарела. Весь мир стораджей ушел вперед, за новыми модными фичами, а HP как продавала в мидрендже – EVA, в high-end ребрендированный Hitachi USP, а в энтрилевеле – DotHill, так и продавала. И допродавалась до катастрофических результатов. Сегодня из компаний в External Storage Top5 только HP теряет объемы продаж, все остальные растут.

Вовремя (надеюсь) спохватившись, HP активно занялась обновлением своего стораджевого портфолио, традиционно “взяв под крыло” несколько небольших компаний с их интересными продуктами, таких как LeftHand и 3Par, и которым явно не хватало веса “продавиться” на рынок. Однако атмосфера долгого застоя в отделе стораджей все еще явно дает о себе знать. Для меня очень показательным стал разбор приведенного ниже документа, как на ладони демонстрирующего текущие проблемы HP StorageWorks как отдела компании: устарелость использованных при подготовке инженеров материалов, крайняя узость эрудиции в области современных технологий, а как результат – низкая компетенция, по крайней мере в анализе продуктов конкурентов (я хочу думать о людях лучше, и верю, что в своих новых системах инженеры HP разбираются куда лучше, чем демонстрируют на системах конкурентов).

Документ сравнительно свежий, написан 11.09.2012 года в программе, зарегистрированной на имя Владимир Коробейников, это человек, работающий на позиции storage presale в HP с 2006 года (эту информацию можно почерпнуть в свойствах файла), я не утверждаю, что текст писал именно он, но эти данные в файле имеются.

Итак, давайте посмотрим, что по поводу NetApp FAS думает HP, и как все обстоит на самом деле, где пресейлы HP ошибаются, от незнания или преднамеренно, где и почему вводят этим документом его читающего потенциального покупателя в заблуждение, а также как намерены бороться за продажи своих систем против NetApp.

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

Continue reading ‘Что HP думает о NetApp, и как все обстоит на самом деле. Часть 1’ »

Вышел Flash Accel 1.2

Если вы еще не запутались окончательно в многочисленных Flash-что-то у NetApp, то вы помните, для тех же, кто запутался - вкратце:
Flash Cache - плата с микросхемами flash memory, устанавливаемая внутрь контроллера на его внутреннюю шину PCIe, и НЕ являющаяся SSD. Обрабатывает только чтение, используя write-акселерацию WAFL для ускорения записи.
Я бы хотел специально отметить, так как многие на это не обращают внимание: именно так, в два слова с большой буквы, потому что flashcache это совсем другой продукт, это опенсорсный проект кэша приложений на flash-памяти, разработанный в Facebook.
Flash Pool - ранее назывался Hybrid Pool, расширение структуры aggregate, позволяющее включать в него SSD (в виде дисков в полках) для еще одного варианта кэширования операций. Работает и на чтение, и на запись. Может работать на одной системе в Flash Cache, расширяя его.
Flash Accel - то, о чем я пишу сегодня. Бесплатная для клиентов NetApp программная система, которая устанавливается на стороне сервера, и позволяет использовать установленные на сервере SSD или платы с flash на PCIe, как локальный кэш на стороне этого сервера. Ориентирована она, прежде всего, на работу с гипервизором VMware ESXi.

Flash Accel позволяет улучшить производительность системы, сняв часть операций ввода-вывода с backend стораджа, что заметно и положительно сказывается на производительности VM.
Он обеспечивает "когерентность" данных между локальным кэшем сервера в flash/SSD и содержимым сетевого хранилища.
Независим от используемых в сервере SSD и плат flash на PCIe.
Позволяет сохранять кэш при перезагрузке системы хранения.
Обеспечивает передачу записей в сетевой сторадж, тем самым обеспечивая целостность данных
Работает как с 7-mode, так и Clustered Data ONTAP.

На прошлой неделе вышла новая версия этого продукта - Flash Accel 1.2, и вот что в ней нового:

  • Поддерживается VMware vSphere 5.1.
  • VM, использующие Flash Accel, теперь могут использовать vMotion и VMware HA.
  • Поддерживатся iSCSI LUN-ы, смонтированные в гостевой OS.
  • Поддерживается работа с ASUP (AutoSupport).
  • Улучшена работа FMC (Flash Accel Management Console).
  • Поддерживаются FusionIO ioDrive card.
  • Управляется через VSC 4.2 (Virtual Storage Console).
  • Появился импорт и экспорт конфигураций.
  • Сохраняется лог консоли.

Схема работы и устройства Flash Accel:

Как вы видите, решение состоит из нескольких основных частей. Это:

Flash Accel Host Agent, устанавливаемый на ESXi как VIB, и обеспечивающий управление локально установленными SSD в физическом сервере. Он создает виртуальное логическое устройство, представленное для ESXi как SCSI-устройство. Будучи созданным на нескольких хостах, оно имеет одинаковый WWN, что позволяет гипервизору со своей стороны трактовать его как единое и совместно используемое, и это позволяет использующим его виртуальным машинам работать в vMotion и VMware HA. На одном хосте вы можете кэшировать до 32 VM.

Flash Accel Agent для VM (Windows), в настоящий момент, к сожалению, есть только для Windows Server 2008 R2, поддержка Linux обещана. Этот компонент необходим для включения-выключения кэширования этой VM, добавляет возможности управления с помошью командлетов PowerShell, коммуницирует с Flash Accel Management Console (FMC), и позволяет интегрироваться Flash Accel в SnapDrive и SnapManager.

Flash Accel Management Console (FMC) – это виртуальный appliance, который ставится в среде vSphere, и позволяет управлять всей конструкцией Flash Accel в целом.

Подробнее про работу FMC можно посмотреть на скринкасте:
https://communities.netapp.com/videos/3416

Flash Accel был протестирован на задачах вида OLTP, и показал, что может снять с системы хранения в локальный SSD-кэш до 80% запросов ввода-вывода сервера, после развертывания Flash Accel загрузка системы хранения снизилась на 50%, кроме того, на 60% снизилась загрузка CPU системы хранения, в сравнении с использованием на ней одного только Flash Cache.

Соответствие команд 7-mode и C-mode

Если вам в скором времени предстоит переход на Clustered Data ONTAP, или если вы админ системы хранения, хорошо знакомый с Data ONTAP 7-mode, которому предстоит администрировать Cluster-mode, то рекомендую посмотреть документ, недавно опубликованный в библиотеке NetApp:

Clustered Data ONTAP® 8.2
Command Map for 7-Mode Administrators

В нем в таблицу собраны команды Cluster-mode, соответствующие, по выполняемым действиям, командам 7-mode. То есть если вы знаете как, допустим, создать том на aggregate в 7-mode, и не знаете какой командой это делается в Clustered ONTAP, то вот этот документ вам поможет.

Брать можно здесь: https://library.netapp.com/ecm/ecm_download_file/ECMP1196780

SnapVault

Продолжим наш курс Back to basics. Кроме репликации SnapMirror у NetApp есть еще один Snap-что-то продукт – SnapVault. Давайте посмотрим, что это и для чего может в жизни сгодиться.

SnapVault, как можно догадаться из названия, это средство, позволяющее сложить снэпшоты (Snap) на долговременое хранилище (Vault), то есть это такое средство бэкапа данных с системы хранения, например главной, рабочей, или, в терминах NetApp – Primary, на резервную, или Secondary.

Зачем? Ну, зачем вообще используется резервное копирование на другой сторадж? Чтобы обезопаситься и обезопасить данные от физического отказа системы хранения. Почму бы для этого не использовать SnapMirror? Очень просто. Потому же, почему RAID это не бэкап. Репликация никак не поможет в случае повреждения непосредственно данных. Поврежденные данные, например испорченные на уровне приложения, точно также отреплицируются на резервную систему, и вы будете иметь два комплекта плохих данных. Тут выручили бы снэпшоты. Но снэпшоты, как вы помните, хранятся на самой системе хранения, непосредственно на исходном томе, такова их принциппиальная конструкция, и если мы вдобавок ко всему, имеем поврежденную или физически потерянную primary систему хранения, то вместе с ней погибнут и данные снэпшотов. Хорошо бы эти снэпшоты уметь выносить куда-то наружу, чтобы потом иметь возможность из них исходные данные не любой сохраненный момент восстанавливать. Вот как раз этим и занимается SnapVault.

Continue reading ‘SnapVault’ »

SnapMirror, часть 2

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

Начнем же подробнее про именно SnapMirror.

Continue reading ‘SnapMirror, часть 2’ »

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.

Striped Volume в Cluster-mode

Как вы уже знаете, архитектура системы хранения NetApp не позволяет, при наличии двух контроллеров, организовать один общий дисковый раздел, доступ к которому имели бы оба контроллера одновременно. Почему так было сделано, отчего, и что это дает полезного – об этом мы уже в блоге говорили, не будем отвлекаться. А сегодня я покажу, как это ограничение может быть снято при использовании Data ONTAP Cluster-mode, новой модели работы со стораджем, которая активно развивается компанией уже не первый год.

В Data ONTAP 8.x Cluster-mode вы можете использовать так называемый режим Striped Volume, при котором доступ к данным на томе может быть осуществлен параллельно с любых контроллеров кластера, в частности с двух контроллеров, составляющих HA-пару.

Для начала надо убедиться, что лицензия Striped Volume введена, что позволяет системе такой том создать.

f3240-sqltest::> license show
(system license show)
Feature Cluster SN Limit Description
————— ———– ——- ———–
Base 1-80-000011 666 Base License w/cluster size limit (nodes)
iSCSI 1-80-000011 666 iSCSI License
Striped_Volume 1-80-000011 666 Striped Volume License
FCP 1-80-000011 666 FCP License
4 entries were displayed.

Раз лицензия есть, то можно создать striped aggregate:

f3240-sqltest::> aggr create -aggregate myAggr -nodes f3240-sqltest-01,f3240-sqltest-02 -diskcount 16 -disktype SAS -raidtype raid_dp -maxraidsize 16
[Job 818] Job succeeded: DONE

Создан aggregate, распределенный (striped) на два узла кластерной системы - f3240-sqltest-01 и fas3240-sqltest-02.

Посмотреть, что получилось можно командой aggr show myAggr.

w680

Данный aggregate распределен на два узла, состоит из 16  дисков, 8 из которых на узле 01, и 8 – на узле 02. Создано также два плекса и две RAID-группы. Это означает, что такой striped aggregate состоит, по сути, из двух “обычных” aggregate. Обратите также, что Volume Style указан как striped.

Понятнее про состав striped aggregate станет после вывода команды aggr member show.

f3240-sqltest::> aggr member show
Aggregate     Size Available Used% State    #Vols Node             RAID Status
——— ——– ——— —– ——- —— —————- ————
myAggr_000 2.15TB    2.15TB    0% online       0 f3240-sqltest-01 raid_dp,normal
myAggr_001 2.15TB    2.15TB    0% online       0 f3240-sqltest-02 raid_dp,normal
2 entries were displayed.

Как видите, striped aggregate myAggr состоит из двух “мемберов”, myAggr_000 и myAggr_001, каждый на своем узле. Если бы мы создали такой aggregate на трех, четырех, и так далее узлах кластера – мы бы получили три, четыре, и так далее под-“аггрегейта”. Созданный же на таком aggregate, поверх него том (volume) и данные на нем, окажутся равномерно распределенными по доступу между несколькими узлами, и операции доступа к ним более или менее равномерно нагрузят все входящие в группу контроллеры.

19/0.196

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.