У меня есть два сервера Dell PowerEdge 2950. Чтобы (надеюсь) устранить любое время простоя, я должен реализовать решение для обнаружения и корректировки отказов компонентов, сбоев среды и т. Д. Обычный сценарий «простой - враг».
С этого момента я буду называть серверы сервер (ы), поскольку реализованное решение может объединить два сервера в один логический сервер (честно говоря, предпочтительнее использовать один логический сервер).
У меня будет ~ 15 тонких клиентов, все они будут указывать на упомянутые выше серверы. Сервер (ы) будет действовать как сервер терминалов. Клиенты подключатся к серверу (-ам) и запустят экземпляр клиентского графического интерфейса. Фактический сервер (ы) сам будет запускать серверная версия того же приложения, обслуживающего клиентский графический интерфейс с необходимой информацией / данными ... (надеюсь, это имело смысл!)
Мне порекомендовали использовать Marathon Technologies everRun 2G программное обеспечение. Хотя это кажется справедливым решением, это также 12000 долларов ... кажется мне немного дорогим (однако, возможно, я демонстрирую отсутствие опыта в этой области) ...
Есть ли более экономичное решение для такого сценария? Я искал решение, включающее Citrix XenServer на данный момент, но еще предстоит продвинуться вперед ...
Как реализовать отказоустойчивость до указанной выше степени?
РЕДАКТИРОВАТЬ: Серверы работают под управлением Windows Server 2003 Enterprise.
РЕДАКТИРОВАТЬ: Чтобы прояснить мое недопонимание, я пытаюсь переключиться на все еще работающий узел в случае аварии. Приложение, которое будет размещено, обеспечивает управление большим количеством дверей и домофонов с электронным замком. Следовательно, если приложение недоступно, никакие двери не откроются, и связь через домофон невозможна. Ой!
РЕДАКТИРОВАТЬ: Что ж, после некоторого изменения объема, финансирования и других нетехнических корректировок проекта решение, которое я продвигаю, фактически не использовало ни один из перечисленных подходов :) Короче говоря, мы поддерживаем два отдельных терминальных сервера; первичный и горячий резервный. Переключение между ними в аварийном сценарии будет выполняться вручную (хотя на самом деле это будет так же быстро, если не быстрее, чем мы изначально ожидали). Аппаратное обеспечение сервера (два сетевых адаптера, два блока питания и два источника бесперебойного питания) обеспечивает необходимую функциональность аварийного переключения. Спасибо за все ваши отзывы, очень признательны!
Marathon - очень тяжелая система, она фактически вдвое снижает производительность ваших систем. Во-первых, я хотел бы убедиться, что у вас есть такие основы, как общее хранилище.
Сегодня VMware может обеспечить высокую доступность, которая эффективно перезагружает сервер при выходе из строя одной из систем. В будущем VMware сможет отслеживать машину так, что, когда один из серверов выйдет из строя, экземпляр будет прозрачно мигрирован «вживую» на другой. служба.
Я хотел бы отметить, что, если вам действительно не нужна HA, обычно лучше иметь простую систему, которая хорошо работает, чем сложная, которая должна быть более надежной, но на самом деле это не так.
Я сомневаюсь, действительно ли вам нужна высокая доступность или вам просто нужно переключиться на все еще работающий узел в случае отказа оборудования. HA будет очень дорого, и с таким небольшим количеством пользователей, я думаю, ваш бюджет не так уж велик.
Рассматривали ли вы возможность использования встроенного в Microsoft каталога сеансов служб терминалов и балансировщика нагрузки? У вас уже есть "Enterprise Edition" Windows Server 2003, так что вы уже "переборщили" с точки зрения затрат на лицензирование при реализации функциональности Session Directory.
Еще немного подробностей: http://download.microsoft.com/download/7/b/3/7b3aa957-4865-427d-9650-789179a5d666/SessionDirectory.doc
Вы можете посмотреть некоторые сторонние инструменты, такие как 2X балансировщик нагрузки, также. (Хотя нет личного опыта с этим ...)
Как упоминал Джеймс, если это действительно так важно, возможно, стоит подумать о загрузке физических серверов с помощью ESX из VMWare. Используя эту инфраструктуру, вы можете использовать Vmotion в сочетании с инструментами высокой доступности VMWare, чтобы позволить серверу беспрепятственно перемещаться между физическими серверами без простоев для конечного пользователя. Для этого требуется SAN, а также отдельный блок для запуска программного обеспечения управления, но программное обеспечение управления может работать на чем-то столь же легком, как настольный компьютер.
Я ручаюсь за Citrix XenServer, но переход на VMWare никогда не бывает ошибкой. Во всяком случае, это может просто повредить корпоративный кошелек.
Как прокомментировал Чарльз, вам действительно нужна SAN (или NAS) или какое-то общее хранилище, чтобы по-настоящему воспользоваться преимуществами функций высокой доступности / VMotion VMWare. Но чтобы ответить на ваши вопросы:
Есть ли более экономичное решение для такого сценария? В настоящий момент я проверял решение с участием Citrix XenServer, но еще не продвинулся далеко вперед ...
Citrix XenServer 5.5 и XenCenter бесплатны (как ESXi), но у IMO есть больше функций, которые приближают вас к вашей цели «устранить любое время простоя». Но при использовании Xen или VMWare вам потребуется общее хранилище, совместимое с требованиями продуктов.
Как реализовать отказоустойчивость до указанной выше степени?
Что ж, ваша общая цель звучала как высокая доступность, и теперь вы просите отказоустойчивости. Две разные концепции в сфере ИТ. Я бы сказал, что учитывая всю представленную информацию, может быть лучшая альтернатива, чем прыгать прямо на высокие затраты на виртуализацию. 15 сеансов - не такая уж большая нагрузка для ваших серверов. Возможно, виртуализация на данный момент - это слишком много, и, возможно, вы сможете обойтись без нее. Распределите нагрузку между двумя терминальными серверами, чтобы снизить нагрузку до тех пор, пока не потребуется больше клиентов, а затем посмотрите на виртуализацию всего.
Другая идея: вы можете виртуализировать с помощью VMWare ESXi или XenServer 5.5 и виртуализировать, но без возможностей HA / VMotion-esque. сейчас. Тогда, когда ты действительно необходимость Чтобы использовать эти функции, купите обновления и установите некоторое общее хранилище между двумя серверами. Таким образом, вам не придется заранее выполнять P2V-преобразования.
Вот несколько вариантов, которые я посмотрю ..
Просто установите все на двух серверах, включая службы терминалов, затем используйте службу, встроенную в сервер Windows, для использования «IP-адреса кластера», чтобы все подключались к одному IP-адресу, и два сервера решали, кто подключается к какой машине, обеспечивая псевдобалансировку нагрузки. ситуация.
Другой вариант - инвестировать в набор инструментов VMWare, чтобы использовать виртуальную машину для служб терминалов, а затем использовать VMotion и параметры высокой доступности, чтобы поддерживать работу виртуальной машины.
В большинстве ситуаций для корпоративной высокой доступности, похоже, требуются два сервера плюс высокоскоростная система хранения SAN или iSCSI, на которой можно сохранять виртуальные машины или общие данные между двумя серверами, а затем службы приложений вашего сервера работают в двух системах, подключенных к хранилищу. сервер.
Возможно, можно будет использовать установку Xen в Linux с использованием DRBD и Pacemaker, но я думаю, что, возможно, достаточно иметь «IP-адрес кластера» в Windows для распределения соединений между двумя терминальными серверами, может быть, с NAS или другим сервером хранения. для совместного использования каталога данных приложения или домашнего каталога данных. Это сработает?
Я думаю, вы немного отредактировали свой вопрос? Либо так, либо я просмотрел слишком быстро :-)
15 пользователей переходят на два сервера с использованием терминальных служб; Я думаю, что с точки зрения бюджета и управления вам все же может быть лучше включить балансировки нагрузки встроены в терминальные службы.
Некоторые предостережения: один пользователь может убить терминал для всех. Мы попросили пользователя уйти, войдя в терминал и просматривая анимацию на сайте weather.com. Через несколько часов использование памяти или ЦП увеличилось до такой степени, что все остальные оказались практически непригодными для использования.
Кроме того, если происходит отключение и пользователь повторно подключается ко второму серверу, они могут быть сбиты с толку, где их приложения использовались, когда сеть вышла из строя, или проблемы с совместным доступом к файлам на сервере домашнего каталога, потому что файл открыт на сервере 1, и они ' re теперь вошел на второй сервер.
Другими словами, сильно полагаться на службы терминалов, независимо от ваших серверов, означает иметь ХОРОШУЮ инфраструктуру. Это означает больше денег на управляемые коммутаторы, надежные кабели и тому подобное. И у вас должен быть ИТ-отдел, готовый контролировать эти серверы на предмет аномалий в случае, если пользователь потребляет ресурсы, поскольку у одного человека может возникнуть проблема, которая каскадно перерастает в сеансы другого пользователя.
Я бы сказал, что, поскольку вы упомянули, что второй компьютер для запуска программного обеспечения управления ESX будет осужден, ваш единственный реальный вариант - это балансировка нагрузки. Практически все другие решения будут включать в себя покупку общего хранилища, которая, вероятно, будет начинаться примерно с того, что вы заплатили за эти два 2950.