Комментарии 30
а что делают с генератором случайных чисел в таких системах? При первой загрузке инициализируется какое-то определенное состояние?
Если я правильно понял, вопрос заключатся в том, какое значение будет на второй ноде при выполнении операции чтения из /dev/random на первой ноде. На самом деле на второй ноде не происходит чтения из генератора случайных чисел. Вместо этого данные реплицируются с Primary ноды.
Не прокатит. Он же честный в интелах, аппаратный. Тоже вопрос возник. Единственный вариант который я вижу — это отключать его совсем. А как же секъюрность тогда?
Не обязательно пользоваться SW генератором, HW также отлично будет работать. При работе кластера происходит полная синхронизация Secondary ноды с Primary.
Что произойдёт если с какого-то момента процессоры вычислительных узлов начнут выдавать разные команды (космическая радиация, перегрев, брак)? Их всего два поэтому нельзя понять в каком сбой, их нельзя перезапустить вместе и повторить вычисления — это reset ОС с ПО и соответственно отказ. Stratus Albireo выберет случайный узел для продолжения работы?
В первую очередь Stratus Albireo проверяет потоки данных на консистентность, получаемые с обоих половинок. Как только система поймет, что поправить ошибку нельзя, произойдёт переключение на исправную ноду.
А которая нода исправна?
Если одна нода вернула 1, а вторая 0? Когда это будет замечено? Придется ли откатывать состояние назад для определения корректной ноды?
Замечено будет сразу. Lockstep проверяет каждый такт. Дальше в работу вступит Stratus Albireo, он выступает в роли арбитра, который и выбирает исправный компонент. Причем делает он это на основе большего количества параметров и цепочек событий (более 500). Как детально работает технология, сам Stratus к сожалению не раскрывает — информация закрытая по коммерческой тайне.
а когда произошло такое расхождение — как про это узнает персонал? Читает в логах ноды, или видит красную лампочку?
Тут все зависит от типа расхождения, если оно критичное, то больная нода будет тут же выведена из строя с нотификацией на передней панели кластера, а админ и поддержка Stratus получат на почту алерт. Максимально подробно можно будет увидеть причину поломки и как система пыталась ее устранить в логах, зайдя на ftSys.
Это похоже на split brain.
При наличии расхождения система выявит причину и постарается устранить сбой. Если ошибка была устранена (тип ошибки correctable), то счетчик MTBF (Mean Time Between Failures) увеличится на 1, а если нет, то данный элемент будет выведен из строя (тип ошибки uncorrectable).

Вот тут не особо понятно, как он его выключает — переводит в слейв или просто гасит до ручного вмешательства?
Вот если бы нод было 3, то обеспечивался бы минимальный кворум, что было бы надежней. Пока же основная точка отказа Stratus Albireo — будет ли он правильно понимать какие данные корректны.
При критичной ошибке выводит из работы и переключает роль Primary на здоровую половинку. Чтобы руками ввести в работу меченный компонент, потребуется скинуть счетчик MTBF.
Есть старая мудрость: в поход бери или один компас, или три :)
>Пока тут весь интернет кричит про наш отечественный жёсткий диск на целых 50 Мегабайт массой 25 килограмм,
>не очень-то понимая, что эта штука может пережить две ядерных войны на дне бассейна

Ну он и не может пережить две ядерных войны на дне бассейна :)

Вы пишете, что процессоры синхронизированы точно, а диски в raid. Правильно я понимаю, что запись на диски обоих серверов выполняется синхронно, то есть пока не будут записаны данные на оба сервера, сигнал о завершении записи не последует? Или есть какая-то задержка при записи на парный диск?
Синхронизацией дисков занимается виртуальный драйвер, который видит диски в обоих половинках и объединяет их в пары (RAID1). Правила чтения и записи соответствуют обычному рэйду.
Попробуйте ради шутки запустить AIDA64, или как там сейчас эверест называется (только не в продакшне!) — увидите, что будет со стратусом.
BSOD
Стратусы очень не любят всяких низкоуровневых дел.
На самом деле, самый здравый вариант использования — это VMWare, а всю работу на виртуалки выводить уже. Кстати, в своё время говорили, что стратус с новых версий перестанет нативно поддерживать красную шляпу, останется только винда и vSphere.
А когда в современных условиях есть смысл решать проблемы отказоустойчивости на аппаратном уровне? Подобная система ведь применяется в очень исключительных случаях, почему тогда не использовать софт, который будет обеспечивать fail-over, как это и делается в случае «бытового ширпотреба»? Какие преимущества у hardware-failover?
Устройство нишевое, конечно, но определенные преимущества просматриваются.

Например, процесс обеспечения fault tolerance не зависит от прикладного кода, а это значит, что:

— Кривой апгрейд/патч софта не сломает FT
— Различные приложения защищаются одинаково, то есть пропадает необходимость обходить и вообще учитывать особенности конкретных реализаций HA/FT в разном софте.
— Можно защищать софт, не имеющий FT. На самом деле, тру-FT, когда данные не теряются вообще, переключение происходит мгновенно, и нет потери производительности, доступен далеко не всегда.
Stratus FT гарантирует отказоустойчивость и высокую производительность как при нормальной работе, так и при failover'е. Причем для подъема FT кластера нужно произвести минимум настроек, таким образом исключаем ошибку со стороны человека, настраивавшего систему. Отдельно отмечу дополнительные потери вычислительных ресурсов при использовании Soft FT кластера, у Stratus FT они минимальны. Где именно можно и нужно применять данное решение, написано в самом конце статьи.

Ну здесь же ничего нового. Всякие бимерские мейнфремы (System z) покруче fault tolerance имеют.

А хотя бы диапазон стоимости сего удовольствия (пусть даже «официально рекомендуемые») озвутить можете? Сотни килобаксов или всего лишь в 2-3 раза дороже, чем просто связка из двух «обычных» серверов?
Интересная железка, очень познавательно.

До космоса правда не дотягивает — там мажоритарное резервирование, по три канала всего, чего только можно :) Чтобы сразу было понятно, который из каналов сломался. Но это достоинств устройства из статьи не умаляет.

Скажите, а точно лицензирование той же Oracle DB будет на одну ноду, а не на обе? Несколько удивительно, учитывая их политику лицензирования, скажем, кластеров виртуализации (если гипервизоры не Oracle).
Лицензия на Oracle действительно потребуется на один сервер, причем не нужно будет покупать дополнительную лицензию на кластеризацию. Данное правило работает и на все остальные поддерживаемые OS: Windows, Linux и ESXi.

Крутил на тестах такую-же железку, но под маркой NEC.
Все отлично, кроме цены.Особенн, как отметил автор — недежность действительно на уровне и не зависит от программной реализации.

-> отключили ноду — потеряли пинг
-> включили ноду — пинги больше секунды
И за такие деньги — такой банальный результат, жаль, а как статья хвалебно начиналась
Подскажите, а сетевые интерфейсы получается имеют одни и те адреса, и всегда включены? На фото все сетевые включены, каким образом это реализовано, что не происходит конфликта адресов?
> Это старая добрая «космическая» архитектура, когда вычислительный процесс проходит сразу два независимых аппаратных пути

Не специалист, но смутно помнится, что «космическая» архитектура предполагает три независимых источника.
И голосование.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.