Как правильно организовать отказоустойчивость ESXi? Здравствуйте, у меня 2 сервера с ESXi 6.0, один обычный, второй за серой сетью, но перед ним маршрутизатор, на котором можно поднять VPN. Первый сервер у Хецнера, второй в подвале. Второй планируется делать резервным, чтобы на него переключаться, в случае проблем с основой. Внутри из сервисов: терминальный сервер, мускуль и 1С с файловиком, обычная структура малого бизнеса. Как правильнее организовать отказоустойчивость, при наличии белого адреса только у одного из серверов?
Во-первых, сначала хотелось бы завести серверы в сферу, сначала казалось, что нужно будет пробрасывать кучи портов ESXi-приблуд и т.д., но пока писал этот пост понял, что сам сервер сферы можно поставить на резерв, так и ресурсы сэкономим и по серому адресу к резерву спокойно сможем обратиться (Кластеру же не нужно в обе стороны между собой общаться белыми адресами?). Если этого сделать не удастся, то планирую снять за 200руб\мес у какого-нибудь Айхора виртуалку на KVM, поднять openvpn-сервер, настроить DMZ в резервный сервер через тоннель, т.о. обеспечив ему якобы белый IP. Затем, написать в iptables этой виртуалки направление RDP на Основной сервер и комментировать его при необходимости переключения. Собственно, есть ли какие-то более гладкие способы решения задачи и приведения всего в божеский вид? Мне не нравится, что пользователям в этом случае обязательно придётся бегать через тоннель. Или можно написать правило, которым vpn-виртуалка будет без тоннеля на основной сервер перенаправлять пакеты пользователей, а уже в случае ЧП заворачивать их в резервный? Всё равно лишний узел в цепи получается. Опять же, можно на самом Хенцере услугу перенаправления заказать, что-то такое было, включать её в случае ЧП. Поделитесь опытом, пожалуйста.
Как правильно организовать отказоустойчивость ESXi? Здравствуйте, у меня 2 сервера с ESXi 6.0, один обычный, второй за серой сетью, но перед ним маршрутизатор, на котором можно поднять VPN. Первый сервер у Хецнера, второй в подвале. Второй планируется делать резервным, чтобы на него переключаться, в случае проблем с основой. Внутри из сервисов: терминальный сервер, мускуль и 1С с файловиком, обычная структура малого бизнеса. Как правильнее организовать отказоустойчивость, при наличии белого адреса только у одного из серверов?
Во-первых, сначала хотелось бы завести серверы в сферу, сначала казалось, что нужно будет пробрасывать кучи портов ESXi-приблуд и т.д., но пока писал этот пост понял, что сам сервер сферы можно поставить на резерв, так и ресурсы сэкономим и по серому адресу к резерву спокойно сможем обратиться (Кластеру же не нужно в обе стороны между собой общаться белыми адресами?). Если этого сделать не удастся, то планирую снять за 200руб\мес у какого-нибудь Айхора виртуалку на KVM, поднять openvpn-сервер, настроить DMZ в резервный сервер через тоннель, т.о. обеспечив ему якобы белый IP. Затем, написать в iptables этой виртуалки направление RDP на Основной сервер и комментировать его при необходимости переключения. Собственно, есть ли какие-то более гладкие способы решения задачи и приведения всего в божеский вид? Мне не нравится, что пользователям в этом случае обязательно придётся бегать через тоннель. Или можно написать правило, которым vpn-виртуалка будет без тоннеля на основной сервер перенаправлять пакеты пользователей, а уже в случае ЧП заворачивать их в резервный? Всё равно лишний узел в цепи получается. Опять же, можно на самом Хенцере услугу перенаправления заказать, что-то такое было, включать её в случае ЧП. Поделитесь опытом, пожалуйста.
Во-первых, сначала хотелось бы завести серверы в сферу, сначала казалось, что нужно будет пробрасывать кучи портов ESXi-приблуд и т.д., но пока писал этот пост понял, что сам сервер сферы можно поставить на резерв, так и ресурсы сэкономим и по серому адресу к резерву спокойно сможем обратиться (Кластеру же не нужно в обе стороны между собой общаться белыми адресами?). Если этого сделать не удастся, то планирую снять за 200руб\мес у какого-нибудь Айхора виртуалку на KVM, поднять openvpn-сервер, настроить DMZ в резервный сервер через тоннель, т.о. обеспечив ему якобы белый IP. Затем, написать в iptables этой виртуалки направление RDP на Основной сервер и комментировать его при необходимости переключения. Собственно, есть ли какие-то более гладкие способы решения задачи и приведения всего в божеский вид? Мне не нравится, что пользователям в этом случае обязательно придётся бегать через тоннель. Или можно написать правило, которым vpn-виртуалка будет без тоннеля на основной сервер перенаправлять пакеты пользователей, а уже в случае ЧП заворачивать их в резервный? Всё равно лишний узел в цепи получается. Опять же, можно на самом Хенцере услугу перенаправления заказать, что-то такое было, включать её в случае ЧП. Поделитесь опытом, пожалуйста.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Для организации отказоустойчивости ESXi в вашей ситуации, вам необходимо использовать различные методы и инструменты. Ниже приведены несколько вариантов решения задачи:
Кластеризация серверов ESXi. Вы можете создать кластер из двух серверов ESXi, настроить кластер HA (High Availability) и DRS (Distributed Resource Scheduler) для автоматического переключения между серверами в случае отказа одного из них.
Резервный сервер. В случае если вы не хотите кластеризовать сервера, вы можете использовать второй сервер в качестве резервного. При возникновении проблем на основном сервере, вручную перенаправляйте трафик на резервный сервер.
Использование VPN и DMZ. Вы можете настроить VPN-сервер на резервном сервере, чтобы обеспечить доступ к нему через серый адрес. Также можно настроить DMZ для перенаправления трафика на основной сервер в случае отказа.
Использование услуги перенаправления трафика. Вы можете обратиться к провайдеру услуг хостинга (например, Хенцер) и заказать услугу перенаправления трафика в случае возникновения проблем с основным сервером.
У каждого из этих методов есть свои преимущества и недостатки, поэтому выбор конкретного подхода будет зависеть от ваших требований к отказоустойчивости, бюджета и уровня технической подготовки. Рекомендуется подробно изучить каждый из вариантов и выбрать наиболее подходящий для вашей конкретной ситуации.