У Oracle RAC есть своя защита на основе кворумов. Что касается хранилища, то здесь на текущий момент защита строится на основе дублирования линков между нодами. Помимо этого в ближайшее время будут доступны агенты для хостов, которые будут выполнять роль арбитров.
На наш взгляд ситуация, при которой откажут ВСЕ линки между шкафами (по паре от каждого сервера, InfiniBand, Ethernet пульс массива), маловероятна. Это больше будет похоже на диверсию. Абсолютной защиты от подобных действий нет.
Так доступ к глубинным алгоритмам и не требуется. При последовательной работе записи/перезаписи поведение одинаково для всех современных накопителей. Если есть разница, например, в триггерах, по которым работает «сборщик мусора», то в глобальном смысле это не так уж и важно, т.к. на общую производительность данное обстоятельство слабо влияет.
Разумеется, внутрь SSD не удастся «влезть». Но перегруппировать входящие данные так, чтобы накопитель думал, будто бы на него в последовательном режиме пишут, возможно. Что, собственно, и реализовано.
Не берусь в полной мере оценивать эффективность вашего метода. Вполне возможно, что это будет работать. Тем более, что в некотором приближении напоминает подход Nettap. Но в наших продуктах применен описанный в статье механизм.
Не так уж и страшно, что данные на SSD пишутся в одно и то же место, т.к. в случае износа этого пространства блоки ремапятся из резервного объема накопителя.
За последние дни уже два таких запроса было. В обоих случаях цель: резервирование пула виртуальных машин в пределах одного датацентра. На два датацентра и аренды канала между ними денег не хватает. Сейчас реализовано «наколенная» сборка из смеси софта, железа и ручного труда. В связи с upgrade хотят сделать «красиво»
Про ваш вопрос ниже помню. Не хочу писать непроверенную информацию, жду ответа инженера.
Запрос на изменение обработается одной нодой, затем результат синхронизируется со второй. В итоге — 2 копии данных. Disaster recovery без виртуализатора СХД, программных агентов и пр.
Еще раз. Если у вас кластер, то в нем только один хост работает с конкретным блоком данным. Хост, имея даже несколько путей до хранилища, отправляет запрос только один раз через один путь (согласно его политике MPIO). Поэтому второй раз этот же запрос через другой путь он отправить не может.
Если у вас с системой хранения работает кластер, то у вашего кластера есть арбитр, не позволяющий более, чем одному хосту работать с конкретным блоком данных. Сам хост одновременно запрос на обе ноды через MPIO отправить не сможет (там round robin или fixed). Т.е. на одну из нод запрос придет раньше.
Еще раз. Основной канал обмена информацией между нодами — это IB 56G. Канал теоретически может выйти из строя. Об этом нужно как-то узнать. Нужен резерв исключительно для проверки пульса. В качестве такого резерва используется 1G Ethernet.
Основной канал для обмена между нодами конечно же IB. Но его как-то нужно дублировать «за недорого». Пульс же все равно с некоторыми интервалами измеряется, latency в Ethernet этому не помеха.
Если IB выйдет из строя, одна из нод перейдет в offline, т.к. синхронизация будет недоступна. Если же Ethernet сломается, то просто alarm.
Про ваш вопрос ниже помню. Не хочу писать непроверенную информацию, жду ответа инженера.
Если IB выйдет из строя, одна из нод перейдет в offline, т.к. синхронизация будет недоступна. Если же Ethernet сломается, то просто alarm.