Назад | Перейти на главную страницу

Виртуализация для отказоустойчивости оборудования?

Может ли кто-нибудь сказать мне, можно ли объединить несколько физических серверов для запуска устойчивой среды виртуализации. Наши серверы становятся все более и более важными для наших клиентов, и мы хотим сделать все возможное, чтобы повысить отказоустойчивость в случае отказа оборудования. Я использовал настольные виртуальные машины, но я не знаком с возможностями виртуальных машин корпоративного уровня.

Идеально было бы иметь несколько физических серверов в нашем центре обработки данных. Несколько виртуальных машин будут совместно использоваться ими для запуска веб-сервера, сервера приложений и сервера базы данных. Если один физический сервер вышел из строя, виртуальные машины должны переключиться на один из других серверов и продолжить работу без каких-либо перерывов.

Это можно сделать? Я понимаю, что даже Google время от времени отключается, поэтому я не ищу совершенства; просто оптимальное решение.

Это отличный повод для виртуализации. Поскольку доступность приложений, а не время безотказной работы отдельных (физических) серверов, становится все более важной для бизнеса, многие организации обнаруживают, что они могут достичь более высокого уровня надежности за счет виртуализации.

Я буду использовать VMWare и Xen в качестве примеров, но с некоторой формой общего хранилища, видимой для двух или более хост-систем, виртуализированные гостевые системы могут быть распределены и сбалансированы по нагрузке между физическими серверами. Основное внимание уделяется качеству общего хранилища, управлению и сетевым / межсоединениям в среде.

Однако одно небольшое предостережение ... Вы должны оценить, какое оборудование и окружающая среда представляют собой угрозу. Качественное оборудование серверного класса включает в себя множество резервов (вентиляторы, блоки питания, RAID, даже RAM) ... Современное оборудование не поддерживает просто потерпеть неудачу довольно часто. Поэтому избегайте чрезмерной реакции, создавая излишне сложную среду, если спецификация серверов более высокого уровня может помочь устранить 90% потенциальных проблем.

Похоже, VMware FT может быть тем, что вы ищете. Он поддерживает «теневой экземпляр» каждой виртуальной машины синхронно с каждой исходной виртуальной машиной и позволяет мгновенно переключаться между двумя экземплярами. Подробнее здесь:

http://www.vmware.com/products/fault-tolerance/overview.html

Любая часть прерывания - довольно сложный вопрос, особенно если сегодня вы переходите с того, что кажется стандартными серверами без отказоустойчивости?

Виртуализация - это вариант, но для полного раскрытия информации вы должны принять обоснованное решение между следующими:

  1. Небольшое прерывание, в порядке нескольких минут.
  2. Без перерыва (Разговаривали миллисекунды).

(2) обычно очень,

  1. Дорого - вам нужна аппаратная мощность N + N. Т.е. для каждого сервера, который вы используете, у вас есть полный резервный сервер с точно таким же программным обеспечением, готовым взять на себя управление в случае оборудование неудача.
  2. Ограничительный - программное обеспечение, которое вы используете для этого, обеспечивает "синхронизацию" машин, обычно через Ethernet. Это означает, что если ваша сеть замедляется, это воля замедлите работу вашего приложения, чтобы все работало правильно. Чтобы этого не случилось, эти машины иметь находиться в одном центре обработки данных и получать любую производительность.

Виртуализация с помощью VMware-FT находится на стадии решения. У Xen есть аналог с everRun, и есть эквивалент для «чистого металла» (без гипервизора).

(1) вполне может быть всем, что вам нужно (Кластеризация)

  1. В зависимости от приложения это может привести к отказу, равному (2). Например. Серверы NFS, такие как NetApp, могут обеспечить плавное переключение при отказе, а клиенты продолжают работу без сбоев и только с кратковременным прерыванием.
  2. «Чуть» терпимее к программным сбоям. Поскольку ни одна из детерминированных инструкций ЦП не синхронизирована, ряд ошибок, таких как состояние гонки, не запускается.
  3. Может позволить запускать разные версии программного обеспечения. Например, обновите узел 1 кластера до пакета обновления 1 Windows Server 2008, подтвердите его правильность, обновите узел 2 до пакета обновления Windows Server 2008.

Я не хочу продавать кластеризацию против отказоустойчивости или голое железо против гипервизора, но, когда дело доходит до высокой доступности, надеюсь, приведенное выше иллюстрирует большое количество вопросов, на которые вам нужно сначала ответить, прежде чем внедрять его.

  1. Какое максимальное время простоя допускают пользователи (будьте реалистичны)
  2. Какие домены простоя вы будете терпеть? Физический сервер? Программное обеспечение? Сеть уровня 2? Слой 3? Датацентр?
  3. Каковы требования к производительности приложения? Виртуализация подходит не для всего, и совсем недавно на виртуальных машинах были приняты приложения, чувствительные к часам, такие как Active Directory (и это определенно не обычная практика). Независимо от того, используете ли вы гипервизор с задержкой и наборы микросхем, виртуализация по-прежнему будет означать снижение производительности, пропускной способности и задержки.
  4. Бюджет, над которым нужно работать.

Эти требования могут быть переведены на такие вещи, как MTTF, и в зависимости от бюджета и навыков вашей команды некоторые решения просто не подходят.

Это выполнимо, и мы делаем нечто подобное, только без автоматической части.

Как отметил @ewwhite, ключ имеет общий пул хранения, который виден нескольким хост-серверам, поэтому, если один хост выходит из строя, это не имеет большого значения, потому что другой хост может взять его на себя. Настроить незаметную автоматическую отработку отказа без прерываний, о которой вы спрашиваете, непросто (или дешево), и, честно говоря, это намного больше проблем, чем стоит, по крайней мере, для подавляющего большинства случаев использования. Современное оборудование не часто выходит из строя, если оно не настроено действительно плохо, поэтому вы получите больше пользы, убедившись, что оно правильно настроено и в среде, которая находится в пределах рабочего диапазона оборудования.

На самом деле мы используем функции аварийного переключения и высокой доступности наших систем только для двух целей. Первый связан с аварийным восстановлением (если наш основной сайт теряет питание или взрывается, или что там у вас, у нас есть критические части, которые отражаются на втором объекте), а второй - во избежание окон обслуживания. Мы используем блейд-серверы и ESX / vSphere, и между возможностью переключения на вторичный сайт и простотой использования vMotion для перемещения виртуальных машин между хостами очень мало, что мы не можем сделать без прерывания обслуживания.

Я бы сосредоточился на том, чтобы сначала настроить эту настройку - как только вы сможете (вручную) вывести что-то из строя, где бы то ни было, вы можете решить, что заставить его работать автоматически будет дороже и сложнее, чем оно того стоит. В теории это звучит достаточно просто и великолепно, но на практике заставить все работать правильно в кластерах или в системе с распределенным гостем может быть очень сложно.