Как устроена память NetApp FAS: NVRAM, NVLOG

System Memory

Память СХД любого контроллера NetApp FAS состоит из модулей оперативной памяти, которые используются для кеширования чтения, и записи, и запитаны батарейкой, отсюда приставка «NV» — Non Volatile MEMory / RAM / LOG. ОЗУ делится на следующие функциональные части: NVRAM, буфер (MBUF) и кеш, о которых подробнее.

* Сброс данных на диски происходит из MBUF, по событию заполненности NVRAM, а не из самого NVRAM`а.

NVRAM & NVLOG

В NVRAM последовательно, на­подобие LOG­записей в БД, собирается NVLOG­записи, в их изначальной форме, как они были присланы хостами. Как только данные от хоста попадают в NVRAM, хост получает подтверждение записи. После того, как произойдёт CP событие, которое генерирует сброс данных из MBUF на диски с последующим подтверждением, NVRAM очищается. Таким образом в нормально работающей СХД содержимое NVRAM никогда не читается, а только пишется, а когда место в ней заканчивается, происходит CP и NVRAM очищается. Чтение NVRAM происходит только после сбоя.

NVRAM в HA

В High Availability (HA) паре, из двух контроллеров NetApp FAS, память NVRAM всегда зазеркалирована, каждый контроллер имеет копию совего соседа. Это позволяет в случае отказа одного контроллера переключить и далее обслуживать все хосты на оставшийся в живых контроллер. После того, как произойдёт CP событие (сброс данных на диск с подтверждением), NVRAM очищается.

Если быть более точным, то каждая из этих двух частей делится ещё на две части, итого 4 для HA пары (т.е. 2 локальные). Сделано это для того, чтобы по заполнении половины локального NVRAM, сброс данных не тормозил новые поступающие команды. Тоесть пока происходит сброс данных из одной части локального NVRAM, новые уже поступают во вторую половину локального NVRAM.

NVRAM в MCC

Для того, чтобы обеспечить защиту данных от Split­Brain в MCC, данные, которые поступают на запись, будут подтверждены хосту только после того, как они попадут в NVRAM одного локального контроллера, его соседа и одного удалённого соседа (если MCC состоит из более чем 2 нод). Синхронизация между локальными контроллерами выполняется через Cluster Interconnect (это внешнее подключение), а синхронизация на удалённую ноду выполняется через FC­IV адаптеры. Эта схема позволяет выполнять переключение в рамках сайта, если второй контроллер HA пары уцелел, или переключаться на второй сайт, если все локальные ноды хранилища вышли из строя. Переключение на второй сайт происходит за секнды.

NVRAM & Pass­Through

Наличие NVRAM позволяет NetApp FAS не переводить в HA­пере, оставшийся в живых один единственный контроллер в режим Pass­Through (запись, без кеша, напрямую на диски). Давайте немного на этом остановимся и начнём с того, зачем вообще нужен кеш записи? Кеш нужен, чтобы обманывать хосты, он подтверждает запись данных до, того, как данные, на самом деле, попали на диски. Зачем вообще переводить контроллер в режим Pass­ Through, если у кеша есть батарейка, при том что у всех А­брендов СХД, есть еще и зеркалирование кеша (HA пара)? Начнем с того, что механизм HA заботится о том, чтобы данные были не повреждены и сбросились на диски при выходе из строя одного из двух контроллеров в HA­паре с одной стороны, с другой стороны, пересчёт чек­сумм для RAID, в кеше, давно не новинка, это ускоряет работу дисковой подсистемы, но именно сброс данных из кеша в уже обработанном на уровне RAID виде оставляет вероятность повреждения данных, которое нельзя будет отследить и восстановить. Так вот, при выходе из строя ещё и второго контроллера, может оказаться так, что данные в следствии оптимизации для записи в RAID частично изменены, а после обработки данных уровнем RAID, есть ситуации когда не возможно отследить целостность изначально поступивших данных. Вот и получается, что данные могут быть повреждены т.е. нет гарантии их целостности и нужно переходить в режим PassThrough с прямой записью на диски. Благодаря тому, что у FAS систем данные сохраняются в виде логов, а не в обработанном виде после WAFL или RAID, а сброс уже обработанных данных происходит в виде накатывания системного снепшота CP единой транзакцией, это позволяет полностью устранить вероятность повреждения данных. Таким образом, во многих современных конкурирующих системах хранения, когда умирает один контроллер в HA паре, мало того, что на второй падает нагрузка от умершего контроллера, так он ещё и отключает свой кеш и оптимизацию записи, что сильно ухудшает скорость работы таких систем. Делается это для того, чтобы записываемые данные таки точно были записаны в не поврежденном виде на диски. Некоторые вовсе не заморачиваются этим вопросом и просто честно пишут об этом «нюансе» в своей документации. А некоторые пытаются обойти эту проблему при помощи «костыля», предлагая покупать не 2­нодовую, а сразу 4­нодовую систему. Так, к примеру, устроена система HP 3PAR, где в случае выхода из строя одного контроллера в 4­х нодовой системе, оставшиеся 3 контроллера будут работать в нормальном режиме записи, но в случае выхода из строя 50% нод система таки перейдёт в режим Pass­Through.

Memory Buffer

Запись на самом деле, всегда происходит в MBUF (Memory Buffer). А из него при помощи запроса Direct Memory Access заставляет NVRAM выполнить копию этих данных к себе, что позволяет экономить ресурсы CPU. В MBUF происходит «распаковка» команд, там же выполняется подготовка данных к записи на диски под названием тетрис (о да, Тетрис! Вы о нём не слышали?, тогда смотрите на 28­й минуте) и другие оптимизации записи для WAFL, там же собирается чек­сумма для RAID (в MBUF, а не в NVRAM).

Тетрис & IO­reduction

Это механизм оптимизации записи и чтения, который собирает данные, в промежутке между CP (CP Time Frame), в цепочки последовательностей блоков от одного хоста, превращая мелкие блоки в более крупные последовательные записи (IO­reduction). С другой стороны, это позволяет без сложной логики включать упреждающее чтение данных. Так, часто нет разницы — прочитать, к примеру 5KB, или 8KB. Это можно было бы использовать для упреждающего чтения — формы кеширования. И когда становится вопрос, какие именно «лишние» блоки стоит упреждающе читать, с тетрисом, вы автоматически получаете ответ на этот вопрос: те, которые записывались вместе с запрашиваемыми.

Кеш

NVRAM и MBUF используются для операций записи, но кроме них есть ещё и системный кеш, для операций чтения. В кеш попадают все без исключения операции чтения. Когда CPU СХД не может найти данные в системном кеше, она обращается на диски, и первое, что она делает — помещает их в кеш для чтения, а потом отдаёт хосту. Далее эти данные могут быть или просто удалены (это же кеш чтения, всё и так есть на дисках) или перемещены на уровень ниже (II уровень кеша), если таковой имеется: FlashPool (SSD диски, кеш на чтение­запись) или FlashCache (PCIe Flash карта, только кеш на чтение). Во­первых, системный кеш, как первого, так и второго уровня, вытесняется очень гранулярно: т.е. может вытесняеться 4 KB блок информации. Во­вторых, системный и кеш II уровня, он deduplication­aware, т.е. если такой блок продедуплицирован или склонирован, он не будет снова копироваться и занимать в памяти пространство. Это существенно улучшает производительность за счёт увеличения попадания в кеш. Так происходит тогда, когда набор лежащих на СХД данных может быть хорошо продедуплицирован или множество раз клонирован, к примеру в среде VDI.

Consistency Point

Технология снепшотирования NetApp оказалась на столько удачной, что она используется в ONTAP буквально повсюду, как базис, для многих других свойств и функций. Напомню, что CP — это данные, уже обработанные WAFL и RAID, благодаря чему, CP — это тоже снепшот, который устроен и работает таким образом: перед тем, как происходит сброс содержимого MBUF на диски, СХД снимает системный снепшот с агрегата, и дописывает новые данные на диск и далее ставит пометку, что данные успешно записались, после чего очищает NVLOG записи в NVRAM. Если в этот момент произойдёт системный сбой, второй контроллер (если он есть) или первый контроллер (после перезагрузки) увидит, что снепшот не успел дописаться, он последовательно вычитает NVLOG записи из NVRAM и сбросит эти данные на диск.

Операция CP выполняется как единая транзакция. По завершении транзакции создаётся новый корневой инод (новый снепшот). Старый снепшот, на уровне агрегата, может быть использован для отката, в случае внезапного перезапуска СХД в середине транзакции.

События генерирующие CP

•  CP — это событие, которое автоматически генерируется при одном из нескольких условий: Прошло 10 секунд

• Заполнилась системная память

• Запущена команда останова контроллера (Halt) 

• Другие.

Кстати, состояние сброса CP, очень часто, может косвенно указывать на то, какие есть проблемы в работе СХД, к примеру когда у вас не хватает шпинделей или они повреждены.

Почему размер ОЗУ не всегда важен?

Как уже было сказано ранее, чек­сумма высчитывается сразу для всего страйпа записываемых данных, а данные никогда не перезаписываются, вместо этого запись происходит на новое место, при этом меняется только метаинформация (ссылки на новые блоки с данными). Это приводит к тому, что нет необходимости в случае перезаписи на одном из дисков считывать каждый раз информацию из остальных дисков в память и пересчитывать чек­сумму. Именно благодаря этой способности кеш у систем NetApp FAS, как правило, меньше чем у конкурирующих моделей — просто в увеличении нет необходимости. Каждая система спроектирована так, чтобы ей хватало ОЗУ для обслуживания максимального поддерживаемого числа шпинделей.

Батарейка и Flash­диск

Как было уже сказано, батарейка запитывает системную память. Но она также запитывает и системный Flash­диск, установленный в контроллере. В случае пропадания электропитания, уже после этого, содержимое памяти будет слито на системный Flash­диск, так СХД может прожить очень долго в выключенном состоянии. Восстановление содержимого в память происходит автоматически при запуске СХД. Батарея выдерживает до 72 часов, в связи с чем, если питание будет восстановлено в течение этого времени, содержимое останется в кеше и восстановление из системного Flash­диска не произойдёт.

SSD и WAFL

Как было сказано ранее, WAFL всегда пишет в новое место, так сделано архитектурно по множеству причин, и одна из них — это работа сброса содержимого MBUF в виде снепшота. Ведь иначе, в случае физической перезаписи блоков, новых, поверх старых, при незавершенной транзакции сброса кеша, это могло бы приводить к повреждению данных. Оказалось, что подход «записи в новое место» очень удачен не только для вращающихся дисков, но и для Flash технологий, из­за необходимости равномерно утилизировать все ячейки SSD дисков.

Выводы

ОЗУ NetApp FAS выполняет не просто ускорение операций чтения и операций записи, но и архитектурно устроена так, чтобы обеспечивать высокую надёжность, скорость и оптимизацию для таких операций. Богатый функционал, множественная степень защиты и скорость работы системного кеша качественно отличают системы A­класса, для высоких продуктивных нагрузок и критически важных, задач.