Как стать автором
Обновить
3
Карма
0
Рейтинг
  • Подписчики
  • Подписки

Построение отказоустойчивого решения на базе Oracle RAC и архитектуры AccelStor Shared-Nothing

У Oracle RAC есть своя защита на основе кворумов. Что касается хранилища, то здесь на текущий момент защита строится на основе дублирования линков между нодами. Помимо этого в ближайшее время будут доступны агенты для хостов, которые будут выполнять роль арбитров.

Построение отказоустойчивого решения на базе Oracle RAC и архитектуры AccelStor Shared-Nothing

На наш взгляд ситуация, при которой откажут ВСЕ линки между шкафами (по паре от каждого сервера, InfiniBand, Ethernet пульс массива), маловероятна. Это больше будет похоже на диверсию. Абсолютной защиты от подобных действий нет.

FlexiRemap® против RAID

Так доступ к глубинным алгоритмам и не требуется. При последовательной работе записи/перезаписи поведение одинаково для всех современных накопителей. Если есть разница, например, в триггерах, по которым работает «сборщик мусора», то в глобальном смысле это не так уж и важно, т.к. на общую производительность данное обстоятельство слабо влияет.

FlexiRemap® против RAID

Основная идея — не перехитрить контроллер накопителя, а подстроиться под его режим работы, ведя учет за расположением данных на нем.

FlexiRemap® против RAID

Разумеется, внутрь SSD не удастся «влезть». Но перегруппировать входящие данные так, чтобы накопитель думал, будто бы на него в последовательном режиме пишут, возможно. Что, собственно, и реализовано.

FlexiRemap® против RAID

Ну зайдите на английскую версию, раз вам так хочется непременно https.

FlexiRemap® против RAID

Не берусь в полной мере оценивать эффективность вашего метода. Вполне возможно, что это будет работать. Тем более, что в некотором приближении напоминает подход Nettap. Но в наших продуктах применен описанный в статье механизм.

FlexiRemap® против RAID

У RAID1 хоть и ниже penalty тоже хватает недостатков в плане разброса блоков с данными по накопителю.

FlexiRemap® против RAID

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

FlexiRemap® против RAID

На дисках конечно. В случае замены контроллера данные будут полностью доступны.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Хост получает ack после фактической записи на обе ноды

Сокращение рисков downtime благодаря архитектуре Shared Nothing

За последние дни уже два таких запроса было. В обоих случаях цель: резервирование пула виртуальных машин в пределах одного датацентра. На два датацентра и аренды канала между ними денег не хватает. Сейчас реализовано «наколенная» сборка из смеси софта, железа и ручного труда. В связи с upgrade хотят сделать «красиво»
Про ваш вопрос ниже помню. Не хочу писать непроверенную информацию, жду ответа инженера.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Да, ограничения на дистанцию есть. Однако немало ситуаций, когда требуется зарезервировать СХД без разнесения копий на значительное расстояние.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Запрос на изменение обработается одной нодой, затем результат синхронизируется со второй. В итоге — 2 копии данных. Disaster recovery без виртуализатора СХД, программных агентов и пр.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Еще раз. Если у вас кластер, то в нем только один хост работает с конкретным блоком данным. Хост, имея даже несколько путей до хранилища, отправляет запрос только один раз через один путь (согласно его политике MPIO). Поэтому второй раз этот же запрос через другой путь он отправить не может.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Одна из нод отключится.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Если у вас с системой хранения работает кластер, то у вашего кластера есть арбитр, не позволяющий более, чем одному хосту работать с конкретным блоком данных. Сам хост одновременно запрос на обе ноды через MPIO отправить не сможет (там round robin или fixed). Т.е. на одну из нод запрос придет раньше.

Сокращение рисков downtime благодаря архитектуре Shared Nothing

Синхронная двунаправленная репликация между нодами.

AccelStor – собственный взгляд на работу All Flash

Еще раз. Основной канал обмена информацией между нодами — это IB 56G. Канал теоретически может выйти из строя. Об этом нужно как-то узнать. Нужен резерв исключительно для проверки пульса. В качестве такого резерва используется 1G Ethernet.

AccelStor – собственный взгляд на работу All Flash

Основной канал для обмена между нодами конечно же IB. Но его как-то нужно дублировать «за недорого». Пульс же все равно с некоторыми интервалами измеряется, latency в Ethernet этому не помеха.
Если IB выйдет из строя, одна из нод перейдет в offline, т.к. синхронизация будет недоступна. Если же Ethernet сломается, то просто alarm.
1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность