Какова методология использования перенаправления и зеркального отображения прозрачного клиента SQL Native Client?

Question

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

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

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

Справочная информация. Я прочитал несколько статей, касающихся использования атрибута соединения SQL_COPT_SS_FAILOVER_PARTNER, и того, что вам нужно указать зеркало в строке соединения, чтобы разрешить прозрачное перенаправление клиента SQLNCLI, но все это кажется немного задом наперед.Почему программист или конечный пользователь должны вмешиваться?Сетевая инфраструктура может измениться.

Я надеюсь, что попытка подключиться либо к главному ИЛИ зеркалу, либо к свидетелю перенаправит меня к правильному принципалу и просто «узнает», что это за зеркало.Я понимаю, что свидетель может управлять несколькими сеансами зеркального отображения базы данных, поэтому может потребоваться что-то еще.

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

Я с нетерпением жду некоторого просветления!

Answer 1

Сначала давайте возьмем свидетеля из уравнения клиента SQL. Свидетель - это всего лишь роман между двумя партнерами, участвующими в зеркалировании, и он не должен принимать клиентские подключения. Для того, чтобы свидетель принял клиентское соединение и «перенаправил» соответствующим образом, потребовалось бы настроить всю инфраструктуру клиентских соединений на месте на свидетеле (в первую очередь входы в систему и разрешения) и потребовал бы, чтобы свидетель был доступен клиенту (на уровне IP) , Если вы считаете, что настройка логинов и разрешений тривиальна, подумайте, почему в MSDN есть специальная статья на эту тему: Настройка учетных записей для зеркального отображения базы данных (подсказка: «пользователи-сироты»).

Далее давайте рассмотрим, как клиент достигнет основного ИЛИ зеркала. Скажем, вы указываете только одно имя сервера в клиентском соединении, принципал, и вы подключаетесь к нему, и он перенаправит вас на «зеркало» (фактически, на новый принципал, так как роли поменялись местами, и он теперь «зеркало»). Это сработало бы, но только в самом неинтересном случае: когда основной и зеркальный сервер оба находятся в сети и имеют роли подкачки. Это не сценарий аварийного восстановления, интересный случай, когда принципал потерпел катастрофический сбой и недоступен. В таком случае прежний принципал является недоступным , и клиент, пытающийся подключиться, просто получит щебетание крикета, там просто нет слушателя, который перенаправил бы его к прежнему зеркалу (текущему принципалу). Вот почему клиент должен знать имена как принципала, так и зеркала.

Теперь, как говорится, конечно, ничто не мешает вам иметь центральное хранилище пар зеркального отображения и клиент сначала подключается к хранилищу и получает имена принципала и зеркала. Вы остаетесь с несколько двусмысленной задачей: обнаружение хранилища и задача поддержания хранилища в актуальном состоянии (достижимо путем использования Уведомления о событиях в Изменение состояния зеркального отображения базы данных событие (EN может доставлять удаленно в центральный репозиторий, см. маршрутизация ). Последняя задача - сделать репозиторий высокодоступным, и повторное зеркалирование является вероятным решением.