mikkisse

Крайне полезно. Спасибо.

В последнее время все чаще задумываюсь о релокации как раз

Хотелось бы отметить, что ближе к последним сериям стало немного хотеться продолжения :)

Сплитбрейн вообразить можно, например, когда система разнесена по стойкам, четное количество мониторов и умирает tor sw. Но тут надо еще подумать на тему того, почему tor один, а не пара.
И скорее это будет не сплитбрейн, а потеря кворума два двух половин. Без кворума и то и это встанет колом, пока не соберется в кучу обратно.

A majority of monitors in your cluster must be able to reach each other in order to establish a quorum.

Все просто, при четном количестве мониторов кворум так же потеряется как и при количестве равном n-1.
Например 3 монитора и 4 могут пережить падение только одного. Потеря двух ломает кворум, потому что в первом случае остается <50% живых, а во втором 50%, что не тянет на кворум.
Аналогично 5 и 6. Потерять 2? — пожалуйста, потерять 3, уже все.

Никто не говорит, что не будет работать на четном количестве. Но зачем платить больше? Или, наоборот, иногда лучше доплатить, чтобы получить кворум большего размера и выдержать больше падений.
Когда улетает один монитор и формируется кворум, я часто наблюдаю, как в этом процессе улетает и второй, не на долго, но система успевает об этом сообщить. Поэтому 5 штук, я думаю наименьшее из более-менее надежных решений, а при 4х тут могло бы быть и неприятно.

Больше тянет не на статью, а на маленькую дипломную.
Хорошая работа.

Продолжайте в том же духе. Ваш блог хорош.

Очень хороший цикл статей. Было интересно почитать.

Отличное описание. Спасибо.

Рад, что статья оказалась полезной.

Долгих лет жизни вашему Сeph'у. (Ну и нашему).

Кто о чем думает. Я почему-то сразу подумал, что речь про VDI :)

Спасибо! Интересно было почитать :)

Отличная статья. Спасибо!

Вот, что сообщает документация Red Hat, например

After an XFS file system is created, its size cannot be reduced. However, it can still be enlarged using the xfs_growfs command

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

Red Hat сильно уступает VMware по части интеграции своих средств виртуализации со сторонними решениями резервного копирования, безопасности и аварийного восстановления.

Интеграция с СРК, например с Veeam, позволила бы действительно смотреть на RHV как на альтернативу. Было бы замечательно.

Отличное описание системы, спасибо :)

Было интересно почитать. Спасибо вам.

Может, сразу 10?

Спасибо за статью.
От себя добавлю EMC — От хранения данных к управлению информацией (2 издание), хорошая книга, хорошо затрагивает сети хранения данных.

Сертификат — не показатель, когда получен после зубрежки дампов и при малом опыте работы. Но, на самом деле и дампы не всегда помогают.
А если взять, например, линейку экзаменов Red Hat, которые представляют собой 3-4 часовую лабу, где нужно выполнить 12-15 шагов по настройке сервера, и, единственная документация, которая есть — это man и заранее не получится зазубрить ни вопросы, ни ответы. Как к таким сертификатам вы будете относиться? Показатель знаний, либо нет?
Ну и опять же, сертификация бывает разная. Бывает CCNA (сдать который может любой, выучив дамп), а бывает CCIE. Кого бы вы взяли на работу? человека с опытом в 20 лет, либо человека, который подтвердил свой статус Cisco эксперта с опытом в 10 лет?

Спасибо за столь развернутое описание.

Спасибо. Как всегда очень интересно. Пишите почаще :)

Спасибо. Пишите побольше таких интересных историй.

Завидую белой завистью :)
Спасибо за информацию! Metrocluster — вещь.

Этой операцией может раз в год кто и воспользуется. Не думаю, что для подобного стоило бы допиливать GUI. Да и потенциально опасные операции лучше прятать с глаз долой.

Интересная задача и решение. Спасибо.

Спасибо! Выкладывайте подобные статьи почаще.

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

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

Конечно же fault tolerance для Бэкап сервера. А вот серверная часть\прокси на линуксе — дело хорошее.

Поддерживаю с кластеризацией

Спасибо за статью!
Быть может вам ее переименовать в NetApp ONTAP Cloud ─ разложим все по полочкам

Как поведет себя Ceph, когда один ЦОД будет изолирован от других?

$ setenforce 0 переводит selinux в permissive режим (аудит ведется, действия записываются в журнал, но правила безопасности не применяются), в котором он находится до перезагрузки, либо до setenforce 1.
Поэтому перманентное отключение делается через конфиг-файл.

Повторение, как говорится.