Привет, сообщество! У нас есть 2 разные 3-узловые конфигурации (с подпиской Community) с репликацией ZFS вместо общего хранилища. Мы знаем, что это не идеально, это не суть 
Недавно у нас были некоторые негативные последствия неожиданных перезагрузок узлов (и одна особенно долгая перезагрузка, в частности), и я хотел бы обсудить, стоит ли использовать очень высокую частоту репликации. Для справки, инцидент 1 (пока просто как справочная информация): Недавно у нас произошла еще одна неожиданная перезагрузка узла, которая, похоже, является еще одним особенным случаем нестабильности с определенными материнскими платами ASRock, как обсуждалось здесь: и ниже. Материнские платы в этом кластере достигли серийных номеров M80-H1025200nnn, но поведение все еще оставляет неприятный осадок, я действительно надеюсь, что у нас снова не будет перезагрузок через день, вздыхаю. Возможно, это было вызвано необычной нагрузкой сети + дискового ввода-вывода в сочетании с драйвером сети virtio, который кажется менее стабильным, чем эмуляция legacy e1000. Инцидент 2: Примерно две недели назад, в начале вечера, я случайно перезагрузил узлы 1 и 3 (из 3 всего) очень случайно остановив corosync (вместо того, чтобы просто приостановить HA, и я даже не помню, чего хотел в первый раз). К сожалению, пока узел 1 вернулся через 2-3 минуты, у узлу 3 потребовалось около 15 минут, чтобы вернуться. К тому времени узел 2 взял на себя контейнеры с узла 3 — используя данные, реплицированные утром. При переключении обратно на узел 3 утренние данные с узла 2 перезаписали более новые вечерние данные на узле 3. (Почему? Хорошо, я понимаю почему, все равно очень неудобно) Мы потеряли полдня данных. Клиенты не в восторге. С тех пор я увеличил частоту репликации до каждые 20 минут, но очень не хочу заходить слишком далеко, из страха, что репликация будет доминировать над нагрузкой системы. Урок 1: К сожалению, неожиданные перезагрузки случаются гораздо чаще, чем запланированное обслуживание узлов или фактические проблемы с оборудованием, и они могут привести к потере данных, если репликация недостаточно частая. Экспериментальный "инцидент" 3: Сегодня, в нашей внутренней конфигурации с в основном несущественными контейнерами без постоянно меняющихся данных, я поэкспериментировал с идеей установки большинства желаемых состояний служб HA в "Ignored", чтобы я мог вручную мигрировать контейнеры, если я решу, что узел не перезагрузится. НО, это невозможно, кластер настаивает на попытке подключиться к неработающему узлу, который он помнит, как узел, на котором работают контейнеры, даже если я поставлю этот узел в режим обслуживания. Я могу сделать резервную копию последних реплицированных данных, выкинуть застрявший контейнер и пересоздать его более-менее. Но это совсем непрактично. Урок 2? Игнорировать нагрузку частой репликации и реплицировать все каждую минуту? Главный вопрос: Как часто следует реплицировать CT и виртуальные машины с непрерывными изменениями данных? Каждую минуту? Нам не хочется, чтобы репликация доминировала над нормальной работой. Вопрос 2: Возможно ли замедлить автоматическое переключение узлов службами, чтобы учесть медленную перезагрузку узлов? Я искал, но ничего не нашел, кроме пожеланий даже более быстрой передачи. Но для многих служб выход из строя был бы гораздо предпочтительнее потери данных, как описано в моем инциденте 2 выше. Боковой вопрос: Кто-нибудь еще сталкивается с неожиданными перезагрузками, с материнскими платами AS Rock или драйвером сети virtio? Спасибо заранее за любой отзыв! С уважением, Christoph
Недавно у нас были некоторые негативные последствия неожиданных перезагрузок узлов (и одна особенно долгая перезагрузка, в частности), и я хотел бы обсудить, стоит ли использовать очень высокую частоту репликации. Для справки, инцидент 1 (пока просто как справочная информация): Недавно у нас произошла еще одна неожиданная перезагрузка узла, которая, похоже, является еще одним особенным случаем нестабильности с определенными материнскими платами ASRock, как обсуждалось здесь: и ниже. Материнские платы в этом кластере достигли серийных номеров M80-H1025200nnn, но поведение все еще оставляет неприятный осадок, я действительно надеюсь, что у нас снова не будет перезагрузок через день, вздыхаю. Возможно, это было вызвано необычной нагрузкой сети + дискового ввода-вывода в сочетании с драйвером сети virtio, который кажется менее стабильным, чем эмуляция legacy e1000. Инцидент 2: Примерно две недели назад, в начале вечера, я случайно перезагрузил узлы 1 и 3 (из 3 всего) очень случайно остановив corosync (вместо того, чтобы просто приостановить HA, и я даже не помню, чего хотел в первый раз). К сожалению, пока узел 1 вернулся через 2-3 минуты, у узлу 3 потребовалось около 15 минут, чтобы вернуться. К тому времени узел 2 взял на себя контейнеры с узла 3 — используя данные, реплицированные утром. При переключении обратно на узел 3 утренние данные с узла 2 перезаписали более новые вечерние данные на узле 3. (Почему? Хорошо, я понимаю почему, все равно очень неудобно) Мы потеряли полдня данных. Клиенты не в восторге. С тех пор я увеличил частоту репликации до каждые 20 минут, но очень не хочу заходить слишком далеко, из страха, что репликация будет доминировать над нагрузкой системы. Урок 1: К сожалению, неожиданные перезагрузки случаются гораздо чаще, чем запланированное обслуживание узлов или фактические проблемы с оборудованием, и они могут привести к потере данных, если репликация недостаточно частая. Экспериментальный "инцидент" 3: Сегодня, в нашей внутренней конфигурации с в основном несущественными контейнерами без постоянно меняющихся данных, я поэкспериментировал с идеей установки большинства желаемых состояний служб HA в "Ignored", чтобы я мог вручную мигрировать контейнеры, если я решу, что узел не перезагрузится. НО, это невозможно, кластер настаивает на попытке подключиться к неработающему узлу, который он помнит, как узел, на котором работают контейнеры, даже если я поставлю этот узел в режим обслуживания. Я могу сделать резервную копию последних реплицированных данных, выкинуть застрявший контейнер и пересоздать его более-менее. Но это совсем непрактично. Урок 2? Игнорировать нагрузку частой репликации и реплицировать все каждую минуту? Главный вопрос: Как часто следует реплицировать CT и виртуальные машины с непрерывными изменениями данных? Каждую минуту? Нам не хочется, чтобы репликация доминировала над нормальной работой. Вопрос 2: Возможно ли замедлить автоматическое переключение узлов службами, чтобы учесть медленную перезагрузку узлов? Я искал, но ничего не нашел, кроме пожеланий даже более быстрой передачи. Но для многих служб выход из строя был бы гораздо предпочтительнее потери данных, как описано в моем инциденте 2 выше. Боковой вопрос: Кто-нибудь еще сталкивается с неожиданными перезагрузками, с материнскими платами AS Rock или драйвером сети virtio? Спасибо заранее за любой отзыв! С уважением, Christoph