Comments 16
Не совсем ясно. 4 минуты недоступности вы называете ha?
Тестирование проводилось на серверах с SATA дисками, согласно рекомендации самого же Proxmox рекомендуется размещать виртуальные сервера на SSD дисках. Цель наша была показать, что при падении физического сервера, виртуальные сервера переключаются и начинают работать.
4 мин мы указали - с запасом, на самом деле сервер переключился быстрее
Стóило бы добавить, что согласно документации всё это нормально работает при latency между нодами в кластере <7ms. Т.е. в идеале в одном датацентре. Судя по обсуждениям в сети, несколько больше ещё можно, но с задержкой в десятки мс про репликацию уже точно лучше забыть.
Так что привлекательный в нынешних условиях сценарий - завести для закрытия разных категорий рисков дублирующие друг друга серверы вне пределов России и внутри страны таким образом не организовать. Я, скажем, осознав этот печальный факт, просто поставил на оба свои Proxmox'а ещё и Proxmox Backup Server и бекаплю их друг на друга. Простой на время ручного поднятия машин на другом сервере в моём случае допустим.
Из личного опыта можно добавить, что сам кластер довольно толерантен к ошибкам сети и сбоям сервисов самого прокса, а вот HA — нет, и уводит ноды в фенсинг вплоть до потери кворума.
А можно расписать наиболее вероятные сценарии факапов?
Пожалуй, тут на статью наберется… на днях сделаю, скину сюда ссыль.
Их может быть много. Например, нельзя настраивать кластер состоящий только из двух серверов, чтобы избежать ситуации split brain. Когда выходит из строя один из физических серверов, второй не понимает, кто из них главный и не может запустить виртуальный сервер на втором хосте. В такой ситуации необходимо добавлять либо общий диск NFS, на который сервера будут помещать информацию о своем статусе, либо настраивать кластер из трех серверов. Третий сервер может использоваться, например, как "сервер-свидетель" - на него не будет настраиваться репликация.
"Дни" несколько затянулись… но держите:
https://habr.com/ru/articles/733640/
Да действительно, тестирование проводилось в рамках одного цода и как Вы и описали, был настроен сервер для резервного копирования - Proxmox Backup Server. Мы не описывали разнесения серверов по разным цодам. В случае разнесения цодов, я бы рассмотрел реализацию идентичного кластера + сервер Proxmox Backup Server и скорее всего синхронизировал бы сервера Proxmox Backup Server и в случае необходимости, восстанавливал бы виртуальные сервера с него. Либо запускал бы виртуальные сервера с самого Proxmox Backup Server, т.к у него есть такая возможность. При этом заранее обговорив и отметив в документе - "Процедуре по резервному копированию и восстановлению", если в компании ведется документирование конечно, время восстановления.
Ну я примерно так и сделал (кое-что ещё в процессе допиливания, плюс есть нюансы, специфические для конкретных виртуалок).
Насчёт "в компании ведётся документирование" - улыбнуло :) У меня малый бизнес - всё сам, всё сам... сам руководитель, сам же и IT-инфраструктуру поднимаю. Виртуалок в proxmox больше, чем сотрудников :) Но, кстати, именно поэтому и пытаюсь сделать всё по-человечески, а не как обычно в таких масштабах делается, - чтобы в перспективе при передаче всей этой рутины нанятому админу всё было чётко и понятно для него.
Вопрос к тем, у кого опыт есть эксплуатации Прокса или Овирта: как оно ведет себя при загрузке процессора или дисков в 100%? Имею ввиду от виртуалок.
Не теряется ли контроль на тем, что на железном сервере происходит? Не сбоит ли контроль вплоть до тормозов веб морды?
Виртуалки можно лимитировать прямо в интерфейсе. Для контейнеров стоит использовать командную строку и cgroups.
При подготовке статьи такие ситуации не моделировали. Мы не грузим сервера под 100%, стараемся не превышать 70-75%.
Proxmox-репликация