Высокая доступность для службы Windows под Windows Server 2003
Мы используем репликацию через центры обработки данных в нескольких европейских странах (таким образом, они не во всем мире друг от друга, но они, конечно, не локальны), и она работает без любой проблемы.
Репликация автоматически перезапустит, если это возможно. Если будет проблема с запросом (например, база данных присутствует на ведущем устройстве а не ведомом устройстве, и запрос использует его), то это потребует ручного исправления по умолчанию (но можно установить его для игнорирования таких ошибок). Если базы данных являются точными зеркалами, то Вы никогда не должны должны быть вручную перезапускать репликацию.
Если у Вас есть два сервера, и ведущее устройство исчезает, то превратить ведомое устройство в 'ведущее устройство', просто остановите репликацию и измените Ваш код (чтобы записать в новое 'ведущее устройство'). Если у Вас есть три или больше сервера, и ведущее устройство исчезает, то остановите репликацию на ведомых устройствах, измените их, чтобы использовать новое ведущее устройство и запуститься снова. Если они не находятся точно в синхронизации (зависит, сколько данных передается, насколько занятый серверы, насколько хороший сетевое соединение, и т.д.), то Вам, возможно, придется сделать больше работы, чем это. Раздел репликации документации MySQL покрывает это более подробно.
Я предложил бы, чтобы Вы удостоверились, что копируете по SSL (т.е. установите пользователя репликации для требования соединения SSL).
Используйте MSCS. Вот то, почему:
Бэкэнд, кластеризирующий (MSCS), является единственным способом кластеризировать сервис (высоконадежное требование), но и NLB и MSCS позволяют Вам кластеризироваться, IP-адрес (послушайте на порте TCP).
Эта конфигурация позволила бы Вам выполнять обоих. Мой единственный протест состоит в том, что это не обычно лучшие практики, чтобы иметь кластер MSCS на фронтэнде (т.е. dishing веб-сайты или что-то как этот); это обычно используется для кластеризации файлового сервера бэкенда, sql/exchange кластеризация, и т.д.
-
1Это не решает проблему повешенного сервиса. Если Вы хотите высокую доступность, необходимо контролировать функциональность сервиса. – Igal Serban 20 July 2010 в 12:44
-
2technet.microsoft.com/en-us/library/cc738051 (WS.10) .aspx Монитор ресурсов обнаруживает отказ, или через Живые Взгляды или Является Живым опросом или через событие, сообщенное ресурсом. Монитор ресурсов называет точку входа IsAlive ресурса DLL, чтобы подтвердить, что ресурс перестал работать. Если IsAlive перестал работать, состояние изменений ресурса в Неудавшемся. Если Вы настроили ресурс, который будет перезапущен при отказе, менеджер по Обработке отказа пытается перезапустить ресурс путем попытки принести его онлайн. – I.T. Support 20 July 2010 в 13:32
-
3"Необходимо ли контролировать функциональность сервиса" - Это - то, какой "Монитор ресурсов" делает да? – I.T. Support 20 July 2010 в 13:33
-
4я не думаю так. Ресурс DLL в этом случае для "универсального сервиса". Все, о чем он заботится, то, что сервис. Сервисы не делают ответа на IsAlive. Ресурс DLL делает. Таким образом, сервис может прекратить функционировать и не лечь спать. Монитор ресурсов не обнаружит эту ситуацию. – Igal Serban 21 July 2010 в 04:01
NLB - загрузитесь балансирует и берет th edead сервис из общего адреса. Точно, для чего это сделано.
-
1Я не могу найти информацию, как NLB проверяет, спустился ли сервис. Это проверяет IP-адрес и порт, если это открыто? – empi 27 May 2010 в 02:25
-
2
-
3Для NLB действительно ли возможно проверить, спустился ли только один сервис на сервер? Я не только должен проверить, понизился ли сервер, но также и если сервис прекратил слушать на определенном порте. – empi 27 May 2010 в 03:06
-
4NLB не имеет никакого способа обнаружить, что сервис не функционирует. Вы могли только пойти этим путем при соединении NLB с пользовательским сценарием, который периодически проверяет состояние сервиса. Мы создали сценарий, который использует команды CMD для выполнения drainstops/failovers на веб-серверах, сервисы которых не опрашивают как "выполнение", я использовал бы кластер MSCS вместо этого для выполнения этого. См. мой отправленный ответ для объяснения... – I.T. Support 20 July 2010 в 11:45
Используйте Балансировку Сетевой нагрузки. Предпочтительно в аппаратных средствах. Некоторые (или все или большинство) устройства могут контролировать рабочее состояние сервера путем отправки запросов HTTP. Или даже отправьте xml и проверку на надлежащий ответ.