Мы меняем хосты для нашего приложения SAAS (IIS + MSSQL) и получаем возможность перепроектировать инфраструктуру. Либо придерживайтесь того, что у нас есть (что хорошо работает), либо виртуализируйте с помощью vSphere.
Текущий:
2x веб-сервера / сервера БД У каждого установлен IIS / MSSQL. Балансировка сетевой нагрузки Windows для распределения трафика между двумя узлами с виртуальным IP-адресом и зеркалированием MSSQL с автоматическим переключением на резерв для БД.
1x следящий сервер MSSQL (маленькая ВМ)
Если один сервер выходит из строя, NLB перенаправляет трафик на другой узел, и MSSQL автоматически переключается. Во время перенаправления NLB может быть 40 секунд простоя.
Возможно:
2 хоста vSphere
1x CentOS Linux SAN (смонтированы как общие ресурсы NFS)
Проблемы не хватает ресурсов для БД и Интернета. В настоящее время сервер Web / DB полностью использует узел и должен совместно использовать узел только в случае сбоя одного из них. Что делать, если SAN выйдет из строя? Было сообщено, что жесткие диски виртуальных машин будут находиться на самих хостах, а SAN будет действовать как резервное хранилище. Я предполагаю, что это решение использует VMware High Availability - потеря данных для БД недопустима. Должны ли вместо этого быть 2 виртуальных машины БД с настроенным зеркалированием MSSQL, но работающие на разных хост-узлах?
РЕДАКТИРОВАТЬ: Плюсы виртуализации - это возможность клонировать машины, легко переходить на новое оборудование, отделять серверы БД / веб-серверы. Есть комментарии по этому поводу?
Любая помощь будет очень признательна!
С vSphere SAN становится (теоретически, поскольку хорошие SAN имеют встроенную избыточность) единственной точкой отказа; но вам нужно разместить там диски виртуальных машин, если вы хотите иметь возможность перемещать виртуальные машины между хостами (это невозможно сделать с локальным хранилищем на хостах).
Кроме того, ваше текущее решение защищает вас от проблем. внутри серверы: должны, например. О.С. один из них будет поврежден, другой сервер останется в сети; если бы вместо этого у вашей единственной виртуальной машины БД была проблема, вы бы просто потеряли ее.
Я бы предложил использовать оба решения: создать среду виртуализации с двумя хостами, а затем разместить внутри них избыточные виртуальные машины, чтобы иметь возможность обрабатывать сбои на уровне ОС / приложения. Но если ваши аппаратные ресурсы ограничены и не могут справиться с этим, просто придерживайтесь текущего решения.
потеря данных для БД недопустима
Хорошо,. вам нужно 3 сервера баз данных, использующих ЗЕРКАЛЬНОЕ ЗЕРКАЛЬНОЕ ЗЕРКАЛЬНОЕ ЗЕРКАЛО и третий как свидетель. В качестве альтернативы отправка файла журнала во внешнюю третью систему в случае возникновения проблем.
Потому что возможно, что sql-сервер повредит базу данных при сбое. Что приводит к неверным данным.
Вам нужны либо резервные копии, близкие к реальному времени, либо постоянно обновляемая копия базы данных.