Живучесть кэша-записи VNX

Живучесть кэша-записи – одна из малоизвестных, но интересных архитектурных особенностей СХД среднего уровня EMC VNX. Лично я вижу в ней взвешенное сочетание двух подходов — разумного и практичного.

Вообще, во всех массивах среднего уровня защита кэш-памяти обеспечивается зеркалированием ее содержимого между контроллерами. Многие массивы зеркалируют даже кэш чтения, но это явно избыточно, так как кэш чтения содержит только те данные, которые уже находятся на дисках, и в защите не нуждается. В VNX есть возможность зеркалировать кэш избирательно, что экономит системные ресурсы – процессорные циклы, да и саму память, что не может не радовать.

Итак, что касается VNX, то любая запись со стороны серверов, попадающая в кэш-записи одного контроллера сопровождается ее дублированием на другой контроллер через специальный высокоскоростной канал PCI-e v2 x4/x8. После завершения зеркалирования кэша сервер получит подтверждение своей записи от массива. Делается это на тот случай, чтобы, когда один из контроллеров вдруг окажется недоступным (плановая перезагрузка, авария), кэш-записи не сброшенный на диски сохранился в онлайн-режиме, и сервера продолжали получать целостный доступ к своим лунам.

До этого момента все достаточно банально, компоненты дублированы, горяче-заменяемы, итд, итп. Короче, пять девяток, и сплошной маркетинг. Интересное кино, как обычно, начинается дальше, когда мы начинаем изучать алгоритм работы в случае сбоя и последующего восстановления.

А в случае сбоя одного контроллера у нас остается еще один, который владеет собственной частью кэша, и зеркальной копией своего партнера. И он, это осознав, объявляет себя владельцем всех лунов на массиве, выполняя операцию внутреннего треспасс-а (т.е. смена владельца по внутренней команде). Избыточности кэша у нас больше нет. Что делать?

С архитектурной точки зрения логично было бы сбросить кэш записи на диски и не записывать больше данные в кэш, заставляя сервера работать с дисками напрямую. Это гарантирует 100% целостность данных. А это главное. Точка. Но вот беда – оказалось, что заказчики СХД хотят не только иметь на них целостные данные, но еще и продолжать работать с ними. Да, работать, даже если произошел сбой контроллера.

А что происходит, когда отключается кэш-записи? Правильно, перед тем как отключиться его содержимое сбрасывается на диски в те адреса, которые являются для каждого блока записи конечным пунктом. При этом любой новый блок уже не пишется в кэш, а идет тоже на диски напрямую. Это все довольно мучительно, особенно, когда надо еще для каждой записи заниматься пересчетом RAID5 и 6. Ни о каких кэш-оптимизациях уже речи быть не может. Так что если дисковый массив в момент сбоя находился под нормальной нагрузкой, появление такого отягчающего обстоятельства как вынужденная работа без кэша, сопровождаемая форсированным сбросом содержимого кэша на диски может стать причиной аварийной остановки приложений, по причине отваливания по таймауту. Т.е. в итоге сбоя контроллера данные остаются целостны, но становятся недоступны. Хотя и временно. Это событие попадает в категорию сервисного кейса Severity 1 (DU/DL – Data Unavailable/ Data Loss). А значит, вносит негативный вклад в доступность дискового массива.

Бог с ним, если речь идет только о незапланированных сбоях – контроллеры СХД хорошо тестируются на заводах, и вполне надежны. Но ведь есть еще и запланированные операции – такие как, например, обновление микрокода массива, требующее поочередной перезагрузки контроллеров. И вот, выходит какой-нибудь очень важный критический патч на микрокод, EMC выпускает циркуляр, требующий планово обновить микрокод. Формально, обновление микрокода происходит в онлайне. Но отключение кэша-записи на тяжело нагруженном 24*7 массиве равносильно остановке работы. Поэтому заказчик откладывает это мероприятие до лучших, но далеких времен.

Сервис ЕМС радостно снимает с себя ответственность за возможные риски связанные с работой массива, не обновленного до минимально рекомендованной версии микрокода. Возможная недоступность и потеря данных в сервисную статистику не идут, маркетинг уверенно заявляет о пяти девятках. А заказчик, у которого стоит такой массив так отнюдь не считает >:-[]
Инженерам EMC, работавшим над задачей достижения новых высот в коэффициенте доступности, тогда еще CLARiiON-ов, пришлось решать для себя эту непростую дилемму. И решение родилось вот какое.

Начиная с версии CLARiiON CX4 (FLARE VNX OE 28 и далее) кэш записи зеркалируется, но не отключается в случае останова одного из контроллеров! Т.е. архитектурно в CLARiiON/VNX пошли на ослабление защиты целостности данных, в пользу повышения коэффициента общей их доступности данных для приложений. Работает это так:

Контроллеры регулярно проверяют друг друга на предмет доступности с довольно высокой частотой – десять микросекунд.

Когда один контроллер (для простоты это будет контроллер А) перезагружается, он сам вежливо оповещает об этом своего партнера (Б). Когда он пропадает неожиданно – партнер узнает об этом с небольшой задержкой.

Выживший контроллер Б объявляет себя Владельцем Кэша, забирает себе под крыло унаследованные от А луны, и кэширует записи на себя, сохраняя при этом разграничение между своим кэшем записи Б и партнера А. О том что Б стал Владелец делается соответствующая запись в кэше записи.

Когда А возвращается после сбоя или перезагрузки, то он первым делом смотрит в своем кэше– «а я Владелец Кэша?». Так как он не владелец, то он спрашивает у Б – «а ты Владелец Кэша?» . Б говорит – «да», и тогда они синхронизуют кэш записи через межконтроллерный канал, контроллер А забирает назад свои луны у Б, и массив начинает работать в штатном режиме.

Если А не восстанавливается, а работа на одном контроллере в течение долгого времени заказчика не устраивает то всегда есть опции
а) отключить кэш записи в ручную и работать напрямую с дисками гарантируя целостность
б) переключиться на другую СХД (например, на Disaster Recovery площадку).

Если работа массива продолжается на одном только контроллере Б, и если вдруг до возвращения контроллера А Владелец Кэша Б из-за какой-то ошибки тоже аварийно перезагружается, то кэш-записи при этом не обнуляется, а удерживается в соответствующей области памяти на контроллере Б.

Если во время перезагрузки Б, возвращается А, то он спрашивает – «Владелец ли я?», если он не Владелец, то он ждет возвращения Владельца, не начиная работать с лунами. Когда Владелец возвращается, то оба контроллера синхронизируют кэш и массив начинает работать в штатном режиме.

Как нетрудно видеть, решающим моментом во всей этой схеме является назначение Владельца Кэша. Как только это случилось – алгоритм заработал.

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

Но так как питание каждого из двух контроллеров задублировано (да, дублированное дублирование питания), то для этого должен произойти четверной одновременный отказ блоков питания, или двойной одновременный отказ обоих резервных батарей. Когда я говорю одновременный, то имею ввиду что сами непосредственные акты сбоя происходят в один момент времени с точностью до 10 микросекунд. Это может произойти при попадании молнии.

Еще один сценарий потери данных, это когда массив работает с одним выжившим контроллером, и происходит жесткий крэш Владельца Кэша, когда он падает и не встает. Итог – замена владельца с потерей Кэша которым он Владел… 😦 Теоретически эта ситуация возможна. Практически сервисная статистика показала, что таких событий за историю платформы CLARiiON меньше одного на 10 тысяч рабочих массивов в течение года.

Однако, для приверженцев «старого доброго» подхода (до FLARE OE 28) с жестким отключением кэша-записи он остался в виде опции.

По личным ощущениям, я хочу сказать, что долгое время с переменным успехом мне приходилось объяснять своим заказчикам, что отключение кэша-записи при отказе/перезагрузке контроллера – это для них очень хорошо. Сейчас я, с большим удовольствием, рассказываю, что кэш записи не отключается, и нахожу при этом гораздо больше понимания.

Теперь важный постскриптум:
Сама идея написать эту статью появилась, когда я писал про использование vault дисков в VNX. Потому что vault — это последнее убежище для write cache, когда отключается питание, или случаются некоторые аппаратные сбои компрометирующие целостность данных. Тут есть важная связь между этой статьей и статьей об использовании vault дисков для хранения пользовательских данных.
Дело в том, что в старом подходе (до 28го микрокода), отключение кэша приводило к резкому сбросу данных сначала на vault диски, а уже оттуда данные в безопасном режиме раскидывались по остальным дискам. Т.е. внутрисистемная (непользовательская) нагрузка, создаваемая в это время на vault диски, может быть «чуть более чем очень много».

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

То есть, понимаете, что в массивах CLARiiON CX3 отключение кэша-записи таким дружелюбным для пользователей образом при обновлении микрокода, или при каких-то одиночных сбоях контроллеров, могло вызывать раздражение. Т.е. vault диски были реально мало для чего пригодны, кроме хранения некритичных к производительности данных именно по причине поведения системы во время выключения кэша записи.

Однако, благодаря появлению технологии “Write cache persistence” частота подобных событий снизилась до уровня, когда использование vault дисков может быть вполне практично, особенно с учетом появления дисков большого размера – 900ГБ SAS и 3ТБ NL-SAS.

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

Живучесть кэша-записи VNX: Один комментарий

  1. Игорь, за запятые, спасибо, как обычно 😉
    Что касается отключения кэша записи и активации cache vault –
    1) Перегрев контроллерной полки
    2) Потеря системного сигнала от обеих резервных батарей SPS, их двойной сбой, или недостаточный заряд обеих батарей
    3) Опционально можно поставить триггер на отключение кэша записи с активацией cache vault при отказе одного из vault дисков

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s