Как правильно организовать отказоустойчивость ESXi?
Здравствуйте, у меня 2 сервера с ESXi 6.0, один обычный, второй за серой сетью, но перед ним маршрутизатор, на котором можно поднять VPN. Первый сервер у Хецнера, второй в подвале. Второй планируется делать резервным, чтобы на него переключаться, в случае проблем с основой. Внутри из сервисов: терминальный сервер, мускуль и 1С с файловиком, обычная структура малого бизнеса. Как правильнее организовать отказоустойчивость, при наличии белого адреса только у одного из серверов?
Во-первых, сначала хотелось бы завести серверы в сферу, сначала казалось, что нужно будет пробрасывать кучи портов ESXi-приблуд и т.д., но пока писал этот пост понял, что сам сервер сферы можно поставить на резерв, так и ресурсы сэкономим и по серому адресу к резерву спокойно сможем обратиться (Кластеру же не нужно в обе стороны между собой общаться белыми адресами?). Если этого сделать не удастся, то планирую снять за 200руб\мес у какого-нибудь Айхора виртуалку на KVM, поднять openvpn-сервер, настроить DMZ в резервный сервер через тоннель, т.о. обеспечив ему якобы белый IP. Затем, написать в iptables этой виртуалки направление RDP на Основной сервер и комментировать его при необходимости переключения. Собственно, есть ли какие-то более гладкие способы решения задачи и приведения всего в божеский вид? Мне не нравится, что пользователям в этом случае обязательно придётся бегать через тоннель. Или можно написать правило, которым vpn-виртуалка будет без тоннеля на основной сервер перенаправлять пакеты пользователей, а уже в случае ЧП заворачивать их в резервный? Всё равно лишний узел в цепи получается. Опять же, можно на самом Хенцере услугу перенаправления заказать, что-то такое было, включать её в случае ЧП. Поделитесь опытом, пожалуйста.
А не проще позвонить провайдеру и спросить сколько у них стоит белый адрес.
С вас будут брать рублей 100 в месяц за белый адрес дополнительно, и работать будет стабильнее и быстрее, чем через "виртуалку на АйХоре"?
Вы не ту проблему хотите решить.
Скорее всего у вас будет не проблема "перебросить клиентов на другой сервер", что элементарно решается хотя бы двумя ярлыками на их рабочих столах,
а гораздо большей проблемой будет, что при выходе одного сервера из строя у вас на втором не будет АКТУАЛЬНЫХ ДАННЫХ.
То есть сервера нужно синхронизировать
Вот это проблемка так проблемка, учитывая объемы данных и узость каналов и непредсказуемость вывода одного из серверов из эксплуатации.
А шлюз-переключалка между серверами - это ерунда по сравнению со основной проблемой.
Меньше хочу светить его, да и переместится он неизвестно когда.
Никогда не пробовал трукрипт (или аналоги) с варей, не знаю даже, на каком уровне его включать, если захочется.
zionkv:
а ты попробуй.
;)
если тебя хоть как-то интенсивно работают пользователи - это очень и очень непросто будет.
P.S.:
и что часто встречается:
думаешь, что все настроено, что все работает хорошо.
но в момент когда нужна вторая машина позарез - выясняется, что синхронизация отвалилась еще месяц назад и/или др. проблемы не дают возможности использовать реплику.
Меньше хочу светить его, да и переместится он неизвестно когда.
Если у тебя обычная торговая фирма - то это лишние затраты ресурсов (в том числе и твоего времени). Никому ваша фирма не нужна, искать где вы там "засветились" на каких IP.
Если же у тебя что-то очень серьезное, то второй сервер найдут люди, которые и слов таких то как IP не знают. Метод называется "паяльник в попу админу и/или директору".
Белые люди обычно делают наоборот -- свои мощности используют в основном, а чужие дата-центры -- как резерв на случай ядерной войны. Это первое.
Второе. Вы собрались 1С-ку по WAN-каналу реплицировать 1С. Сколько пользователей 1С-ки всего? 1, 10, 100?
Третье. vSphere для репликации, vMotion и других подобных операций требует задержек не более N ms. Проверьте, сможете ли вы выполнить сетевые требования на должном уровне. А то как бы не пришлось строить растянутые кластеры на гостевых технологиях (MS SQL, например, если база 1С в MS SQL).
Ну и 4-ое -- вообще непонятно, зачем для резерва выбирать сервер в другой стране, да ещё торчащий напрямую в интернет.
