Кластер ms sql server 2016

Кластер ms sql server 2016

Группы доступности AlwaysOn, мой опыт

Группы доступности AlwaysOn, мой опыт

Добрый день уважаемые читатели, продолжаем с вами изучать серверные технологии, сегодня на повестке дня, мы рассмотрим вопрос, о группах доступности AlwaysOn, в SQL Server 2016. Поговорим, как создать отказоустойчивый кластер из него (Failover Cluster Instance). Уверен, что как только у вас появляется полезный сервис с высокой посещаемостью, то у вас остро встает вопрос, о том как обеспечить надлежащий уровень доступности, если да, то вы попали на правильную статью, тут все это рассматривается.

Что такое AlwaysOn в SQL Server 2016

Группы доступности AlwaysOn — это мощнейшее средство в составе дистрибутива SQL, дающее возможность для администраторов баз данных, реализовать очень высокий уровень доступности (HA, high availability) с помощью кластерных технологий и не обязательно иметь общую файловую область (Shared Storage), уменьшить время восстановления (disaster recovery, DR) после аварии или сбоя оборудования. Данная технология, является в моем понимании заменой предыдущей технологии по зеркалированию базы данных (Database Mirroring). Если вы ее уже пробовали на практике, то знаете, что это не синхронная репликация логов транзакций и базы данных.

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

Модель защиты AlwaysOn

Для того, чтобы что-то развернуть и управлять этим, необходимо разобраться в функциональных возможностях и тонкостях технологии, давай посмотрим за счет чего обеспечивается высокая доступность и отказоустойчивость БД в SQL Server 2016:

  • Первое на что следует обратить внимание, это на уровень серверов (физическое железо + операционная система Windows Server 2012 R2), тут отказоустойчивость реализована, с помощью кластера WSFC (Windows Server Failover Cluster — отказоустойчивый кластер Windows). Именно данная технология мониторит состояние членов кластера и принимает решение о координации при отказе.
  • Далее следует уровень SQL Server 2016, тут отказоустойчивость реализовывается возможностями отказоустойчивых кластерных экземпляров AlwaysOn (их еще называют инстансами). Он разворачивается на нужном количестве узлов кластера Windows Server, и в случае недоступности одного из узлов, будет производится переключение.
  • Технология групп доступности AlwaysOn — реализуется на уровне баз данных, состоит из одной и более БД, которые будут переведены на дублирующий SQL Server в случае отказа.
  • Еще хочу отметить уровень, на котором подключаются клиенты, тут соединение возможно, как напрямую к экземпляру SQL Server, либо же используя virtual network name (VNN, виртуального сетевого имени), оно служит для скрытия уровней отказоустойчивого кластера Windows Server и групп доступности AlwaysOn, так же делает перенаправление запросов клиентов на нужные экземпляры SQL Server 2016 и реплику БД

Что входит в группы доступности AlwaysOn

Если обратиться к сайту Microsoft, то там можно обнаружить вот такие вещи, AlwaysOn легко взаимодействует со средой баз данных доступности, данные группы доступности содержат набор баз данных получателей и источников. Реплики доступности, как раз и размещают базы данных доступности. Реплики доступности бывают вот такие:

  1. Так называемая, первичная реплика, она содержит БД, являющиеся источником реплик
  2. И вторая реплика, которая содержит набор БД получателей, напоминаю, их может быть до 4, о чем я уже писал выше.

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

Как я и писал выше, вам потребуется развернуть отказоустойчивый кластер Windows Server Failover Cluster на Windows Server 2012 R2 и выше. Ваши реплики будут располагаться на разных его узлах, но в рамках одного Windows Server Failover Cluster, в группах доступности отсутствует роль следящего.

Подготовительные требования к группам доступности

Ниже я хочу написать требование, которые вам необходимо выполнить перед созданием кластера WSFC и AlwaysOn:

  • Для выполнения нашей задачи вам потребуется редакция SQL Server 2016 Enterprise (подойдет и 2012, но так как он уже более старый, я использую следующие версии)
  • Наличие WSFC (Windows Server Failover Cluster), так как без отказоустойчивых хостов, вам делать нечего
  • Одинаковый SPN (кодировка на уровне SQL сервера)
  • Созданные отдельные записи для запуска служб SQL сервера

Создание кластера высокой доступности без общих дисков

В моей реализации нет общих дисков для кворума и для сиквела, я буду использовать файловую шару для Quorum, а базы данных будут локальные. Давайте посмотрим основные требования к созданию кластера WSFC (Windows Server Failover Cluster):

  • Хостов нужно как минимум два, думаю это понятно
  • Если ваши хосты являются частью Active Directory, то создавать WSFC, необходимо из-под доменной учетной записи, в противном случае вы получите ошибку:

  • Все узлы кластеризации, должны иметь одинаковые операционные системы, в моем случае, это самая стабильная на текущий момент Windows Server 2012 R2.
  • Если вы используете общие диски с системы хранения данных или ISCSI диски с обычных серверов, то вам необходимо их подключить и разметить заранее.
  • Из необязательных рекомендаций Microsoft, для лучшего управления и применения групповой политики, требуется создать отдельное организационное подразделение (OU)
  • Убедитесь, что та учетная запись от имени которой вы будите создавать кластер, имеет права администратора на всех серверах, входящих в него.
  • Убедитесь, что у данной учетной записи, есть права на создание объектов компьютеров в Active Directory, если их нет, то либо нужно получить права, либо попросить системного администратора создать их заранее, об этом я расскажу ниже.

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

Открываем пункт "Средства" в диспетчере серверов и находим там строку "Диспетчер отказоустойчивости кластеров".

В открывшейся оснастке, для начала я вам советую провести тестирование вашего оборудования на соответствие необходимым требования. Для этого щелкаем правым кликом по значку диспетчера и из контекстного меню выбираем пункт "Проверить конфигурацию"

На окне "Выбор серверов или кластера" указываем DNS имена ваших серверов (если хотите, то можете и ip адреса добавить)

На следующем шаге будет два пункта:

  • Выполнить все тесты > актуально для первого раза
  • Выполнить только выбранные тесты > удобно когда, точно знаете, что до этого исправляли и хотите проверить результат.

Мастер проверки конфигурации, покажет все тесты, которые будут произведены, обратите внимание она для вашего удобства, разбиты на категории.

Запускается тестирование, зеленым цветом, будут подсвечены удачные прохождения, красным, требующие внимания администратора.

Через короткое время вы увидите, результаты, можете ли вы создать кластер с такими серверами и настройками или нет, советую просмотреть отчет.

Очень часто я встречал в государственных организациях, недостаточные права для выделенной учетной записи. Вы вполне можете встретить, очень критическое предупреждение"

Все я добился того, что остались не значительные предписания, щелкаем правым кликом по значку диспетчера и из контекстного меню выбираем пункт "Создать кластер"

Добавляем нужные узлы.

Задаем имя кластера в виде 15 символьного имени NETBIOS и статический Ip адрес и нажимаем далее

На данном шаге вы можете увидеть ошибку:

Суть данного сообщения в том, что администратор домена, вам заранее создал объект имени кластера или CNO, но он включен, хотя по рекомендации Microsoft, должен быть отключен. (https://technet.microsoft.com/ru-ru/library/dn466519(v=ws.11).aspx) Про подготовку CNO я расскажу чуть ниже.

Жмем далее. У вас начнется собираться кластер, если у вас не выполнены все требования, то вы увидите сообщение:

Чаще всего это бывает из-за нехватки прав.

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

  • Развертывание отсоединенного от Active Directory кластера, не требующего создания объекта компьютер в домене
  • Либо при необходимости его внесения в домен, вам нужно создать требуемые условия, а именно подготовить объект имени кластера или CNO, чем мы и займемся ниже, это маленькое лирическое отступление, для тех людей у кого не хватает прав в AD, не выделенное заказчиком.

Подготовка объекта имени кластера или CNO

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

  • У вас должны быть права на организационную единицу в которой располагаются сервера, необходимые для добавления в кластер WSFC

У пользователя, создающего кластер, есть разрешение на создание объектов-компьютеров для подразделения или контейнера, в котором размещаются серверы, которые войдут в кластер (https://technet.microsoft.com/ru-ru/library/dn505754%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396)

  • Убедитесь, что выполнены вышеописанные требования к созданию кластера, в начале статьи
  • Если прав вам не дадут, то необходимо выполнить подготовку к созданию точки административного доступа

Подготовка кластерных объектов-компьютеров в доменных службах Active Directory, начинается с CNO создания виртуальных объекты-компьютеров (VCO).

Откройте оснастку Active Directory — пользователи и компьютеры. У вас в компании должна быть система именования учетных записей, и руководствуясь ей, вам необходимо заранее выбрать имя для кластера и имени учетно записи пользователя, от имени которого он будет создан, ей бы дадим сейчас права. Из рекомендаций Microsoft есть пожелание для кластерных объектов делать отдельную OU. Такие подразделения удобны для администрирования.

Создаем нужную OU, правым кликом по нужному месту в вашей иерархии AD.

Теперь создадим новый объект компьютера, это у нас будет (точка административного доступа CNO)

Указываем имя нашего кластера.

И как я писал выше в требованиях, ее необходимо выключить.

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

Читайте также:  Китайский или японский язык учить полезнее

Теперь необходимо дать нужному пользователю права на организационную единицу. Щелкаем правым кликом по OU и выбираем свойства. Переходим на вкладку "Безопасность" и добавляем нужную группу безопасности или учетную запись пользователя.

Предоставляем ей полны доступ и сохраняем.

Теперь, когда подготовительные требования выполнены, вы спокойно соберете кластер.

Далее необходимо настроить кворум. В оснастке "Диспетчер отказоустойчивости", делаем правый клик по названию сервера и из контекстного меню выбираем "Дополнительные действия > Настроить параметры кворума кластера"

Далее выбираем свидетель кворума.

Говорим, что настройки будут лежать в общей сетевой папке "Настроить файловый ресурс-свидетель"

Задаем путь до сетевой папки.

Проверяем все настройки и подтверждаем их.

Если учетной записи не хватит прав на сетевую шару, то вы увидите ошибку:

Посетителей: 13904 | Просмотров: 20070 (сегодня 0) Шрифт:

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

операций. За 13 лет работы с SQL Server™ я внедрил множество кластеров, и в каждом случае были свои особенности. Этот опыт позволил мне сформулировать ряд советов и рекомендаций, которые помогут сделать работу с кластерами проще и успешнее.

Кластеры серверов позволяют выгодно применить встроенные возможности кластеризации программных продуктов семейства Windows Server® (выпуски Enterprise Edition). Нужно отметить, что операционная система Windows Server 2003 больше подходит для целей кластеризации, чем операционная система Windows 2000 Advanced Server. Чтобы воспользоваться всеми преимуществами кластеризации, необходимо соответствующее оборудование, и это требует определенных затрат. Недостаточно просто «слепить» пару серверов и общий диск; нельзя также полагаться на тот факт, что отдельные компоненты оборудования входят в Каталог Windows® (в прошлом – список совместимого оборудования HCL). В Каталоге Windows должна присутствовать вся система. Однако это не повод для разочарования: существуют одобренные экономичные решения для кластеризации. На рис. 1 показана типичная конфигурация кластера.


Figure 1 A typical cluster

Разумеется, перечень вещей, которые нужно учитывать при кластеризации, не ограничивается оборудованием; необходимо также выбрать правильный выпуск сервера SQL Server 2005. Выпуск Enterprise Edition предоставляет возможности кластеризации, а также другие полезные возможности, такие как использование большего количества процессоров, распределенные и обновляемые секционированные представления, встроенная доставка журналов, автоматическое использование индексированных представлений. В случае наличия лицензии для выпуска Enterprise Edition следует подумать о кластеризации независимо от того, есть ли в организации от двух до восьми серверов, необходимых для формирования традиционного кластера (о кластерах с одним узлом речь пойдет чуть позже). Если используется выпуск SQL Server 2005 Standard Edition, можно установить кластер из двух узлов.

Операционная система Windows Server 2003 выпусков Enterprise Edition и Enterprise Datacenter Edition поставляется со встроенной кластеризацией. Достаточно просто запустить Администратор кластера и настроить кластер. Узлы можно добавлять по одному или все сразу. Аналогичным образом при установке сервера SQL Server можно выбрать установку на отдельный некластеризованный сервер или установку виртуального экземпляра на кластер. При выборе установки виртуального экземпляра можно выполнить установку на все узлы кластера, на избранные узлы или даже на один узел кластера.

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

Кластеры с одним узлом

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

Возможность последующего добавления узла полезна не только ради повышения уровня доступности. Рассмотрим ситуацию, когда в какой-то момент обнаруживается, что мощность сервера недостаточна. Это означает необходимость миграции, то есть затраты времени и сил. При наличии кластера с одним узлом миграцию можно будет выполнить намного легче и с меньшим временем простоя. В кластер добавляется новый узел; на новый узел устанавливаются двоичные файлы и пакеты обновлений сервера SQL Server, а затем с помощью процедуры перехода на резервный ресурс выполняется перенос сервера на новый узел. После этого нужно установить дополнительные исправления, выпущенные после пакета обновлений, и, наконец, исключить старый узел. Время простоя ограничивается временем перехода на резервный ресурс и установки обновлений (если необходимо).

Поскольку все узлы в кластере должны быть одинаковыми, то чем раньше предприняты действия по приобретению дополнительного узла, тем лучше. Если прождать слишком долго, производство нужного оборудования может быть прекращено. На одном проекте мне нужно было перестроить узел в кластере серверов SQL Server 2000. Я переложил ответственность за базовое построение компьютера на администратора сети и операционных систем, а затем пришел, чтобы добавить компьютер обратно в кластер и подготовить его к работе в качестве узла SQL Server. Все шло хорошо, пока я не выполнил переход на резервный ресурс на новый узел. К моему великому сожалению, сразу же случился обратный переход. В двух словах, произошло следующее: несмотря на то, что я подготовил подробный документ по построению нового кластера, включавший добавление на оба узла служебных учетных записей кластера и сервера SQL Server, эти указания были выполнены неточно. Администратор не добавил эти служебные учетные записи на перестроенный узел, поэтому права, имевшиеся у этих учетных записей до перестроения, больше не существовали.

На обнаружение причины у меня ушло много времени. Однажды мне пришло в голову посмотреть на состав локальных групп. Как только я добавил эти две учетные записи, переход на резервный ресурс прошел благополучно. Это навело меня на размышления. Перестроение узла делается нечасто, а если делается, то в экстренной ситуации. Хотя я и подготовил документацию, мои указания не были исполнены. Мы могли бы автоматизировать часть, ответственную за безопасность, написав небольшой сценарий, который бы добавлял эти две учетные записи и выполнял бы другую необходимую настройку. Однако в сервере SQL Server 2005 эта процедура усовершенствована. Установщик требует, чтобы для служебных учетных записей SQL Server задавались группы на уровне домена.

Разумеется, это заставило меня задуматься еще. Ведь можно создать сценарии, которые бы вызывали программу CLUSTER.EXE для добавления узла в сервер кластеров Microsoft® (MSCS). Все, что нужно сделать, – это передать сценарию имя узла, а остальное он сделает сам. В экстренной ситуации автоматизация – настоящий друг.

Иногда узел добавляется в кластер не для замены другого узла. Возможно, в кластер требуется добавить дополнительные экземпляры сервера SQL Server, и каждому экземпляру требуются отдельные дисковые ресурсы. Хотя на одном узле может быть запущено несколько экземпляров сервера, в такой ситуации им приходится делить между собой процессор и ОЗУ, что приводит к снижению производительности. В идеальной ситуации на одном узле должен быть запущен только один экземпляр. Как гарантировать это при переходе на резервный ресурс? Очень просто! На одном из узлов не должно выполняться ни одной службы, а на каждом из остальных узлов должно быть запущено по одному экземпляру сервера SQL Server. Это и есть определение кластера «N+1»: N экземпляров, запущенных на N+1 узлах. Лишний узел является запасным.

Обновление сервера SQL Server

Обновление кластеризованного экземпляра SQL Server – ответственное мероприятие. Экземпляры кластеризуются не просто так, а ради повышения продолжительности бесперебойной работы. Сервер SQL Server 2005 содержит большое количество полезных улучшений, позволяющих сократить время простоя в случае необходимости обновления сервера.

Какие имеются варианты? Сначала рассмотрим самое дорогостоящее решение: создание совершенно нового кластера, которое потребует новых серверов и, возможно, новой сети области хранения данных (SAN). Вероятно, удастся сохранить существующие сетевые коммутаторы, но этим исчерпываются возможности использования старого оборудования. Очевидно, это недешевый подход, но у него есть преимущества. Новое оборудование, как правило, работает намного лучше старого; скорость и емкость дисков непрерывно увеличиваются. Следовательно, производительность увеличится уже благодаря обновлению оборудования. Чтобы всегда иметь современное оборудование, возможно даже имеет смысл брать его в аренду.

Когда оборудование установлено, можно создать новый виртуальный сервер SQL Server и скопировать на него производственные базы данных, а затем подвергнуть новую систему всестороннему испытанию, чтобы устранить возможные неполадки до наступления срока переброски сервера. При этом следует обязательно создать сценарии для переноса учетных записей пользователей с существующего сервера на новый. (См. статью support.microsoft.com/kb/246133 (на английском языке). Также имеет смысл обновить сценарий построения учетных записей на случай внезапного полного отказа.)

Для сведения к минимуму времени простоя скорее всего потребуется использовать доставку журналов, за исключением случаев, когда базы данных очень маленькие и есть период времени, когда ни один пользователь не подключен. Доставку журналов можно выполнить непосредственно перед переброской. Затем следует отсоединить пользователей, вырезать и доставить окончательный журнал и указать приложению на новый экземпляр. (Ниже, в разделе о зеркальном отражении баз данных, рассказывается об интересной альтернативе доставке журналов.) Если используются DNS-псевдонимы, то, скорее всего, даже не придется указывать приложениям на новый экземпляр. Вместо этого нужно будет просто обновить DNS-псевдоним. Такой подход имеет следующее преимущество: в случае необходимости остановки процесса миграции на полпути и возвращения в исходное состояние это исходное состояние, по крайней мере, будет в наличии.

Можно выбрать менее дорогостоящий вариант, но он потребует более сложного предварительного планирования. Кластер может поддерживать более одного экземпляра сервера SQL Server, но каждый экземпляр должен иметь собственные дисковые ресурсы. Поэтому при организации сети области хранения данных (SAN) следует зарезервировать один номер логического устройства (LUN) для будущих обновлений. Чтобы выполнить обновление, следует установить двоичные файлы сервера SQL Server на этом дисковом ресурсе. Далее следует провести испытания системы и, когда все будет готово, завершить работу текущего сервера SQL Server, переместить дисковые ресурсы из старой группы SQL Server, обновить зависимости и перевести новый экземпляр сервера SQL Server в оперативный режим. Далее нужно присоединить базы данных из старого экземпляра, и можно считать операцию выполненной. (Вы же создали резервные копии заранее, не так ли?)

Читайте также:  Mytoys купон на скидку

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

Как вариант, можно поместить два экземпляра сервера SQL Server в сеть области хранения, если в ней достаточно места. Далее следует восстановить производственные резервные копии (и доставить журналы) на новый экземпляр сервера и продолжить приблизительно так же, как описано выше. Однако теперь есть пути для отступления. По окончании миграции можно освободить ресурсы сети области хранения от старого экземпляра. Стоимость этого действия будет равна только цене новых дисков.

Для начала опровергнем одно распространенное заблуждение. Кластеризация MSCS используется для повышения уровня доступности, а не для балансировки нагрузки. Кроме того, сервер SQL Server не имеет встроенной возможности автоматической балансировки нагрузки. Балансировать нагрузку необходимо посредством физического проектирования приложения. Что это значит?

С ростом размеров таблицы следует ожидать ухудшения быстродействия, в частности, при сканировании таблицы. Когда количество строк достигает миллионов и миллиардов, обычным решением до сих пор являлось использование секционированных представлений. Эти секционированные представления состоят из таблиц с одинаковыми схемами, объединенных с помощью инструкций UNION ALL. Кроме того, для различения таблиц-компонентов устанавливаются проверочные ограничения (инструкция CHECK), что предотвращает дупликацию данных в секционированном представлении. Если столбец, используемый в проверочном ограничении, является частью первичного ключа, то представление является обновляемым.

Если таблицы-компоненты расположены на отдельных файловых группах, то для повышения быстродействия дисковой подсистемы можно распределить файлы этих файловых групп по разным физическим дискам. Можно даже размещать таблицы в разных базах данных. Однако размещение всех данных в одной базе данных позволяет использовать возможности секционирования таблиц, предоставляемые сервером SQL Server 2005. Реализовать такое секционирование значительно проще.

Но допустим, что уже испробованы все возможности секционирования таблиц или создания (локальных) секционированных представлений, а быстродействие все равно не на высоте. Если вы пользуетесь сервером SQL Server 2000 или SQL Server 2005, можно воспользоваться распределенными секционированными представлениями. Основное их отличие заключается в том, что таблицы-компоненты могут располагаться на разных экземплярах сервера SQL Server, и эти экземпляры могут быть установлены на кластере с конфигурацией «N+1». В чем же смысл такого решения? Если таблица-компонент в секционированном представлении становится недоступной, недоступным становится и всё представление. Если же сделать эти таблицы-компоненты частью кластера, это предоставит стабильность, необходимую для обеспечения быстродействия и балансировки нагрузки.

А так ли нужен кластер?

Возможно, у вас есть несколько лишних серверов, но они отсутствуют в разделе кластеров Каталога Windows. Не хотелось бы покупать новые серверы только для поддержки кластера, когда есть свободные серверы.

Заманчивой альтернативой кластеризации является зеркальное отражение баз данных. Для зеркального отражения необходимо три компонента: экземпляр, в котором размещена отражаемая база данных (основной сервер), резервный (зеркальный) сервер и, если требуется автоматический переход на резервный ресурс, третий (следящий) сервер. В двух словах, при зеркальном отражении базы данных происходит следующее: транзакция в базе данных на основном сервере запускается также и на зеркале. Если на основном сервере происходит сбой, возможен переход базы данных на резервный ресурс – зеркальный сервер. При наличии следящего сервера это произойдет автоматически. Зеркальное отражение необходимо настраивать для каждой базы данных вашего приложения; для системных баз данных зеркальное отражение недоступно.

В отличие от кластера, зеркальный сервер – это отдельный экземпляр SQL Server; он может быть расположен на расстоянии тысяч километров от основного сервера. Его кэши наполняются посредством действий по обновлению, которые происходят в результате транзакций, дуплицируемых с основного сервера. Разумеется, предполагается, что на зеркальном сервере не происходит никаких действий кроме получения зеркально отраженных транзакций с основного сервера. Переход на резервный ресурс в этом случае, как правило, происходит быстрее, чем в кластере, так как на зеркальном сервере SQL Server уже запущен. Поскольку кэши уже заполнены (по крайней мере, частично), начальное быстродействие не такое низкое, как в сценарии с кластером. Также следует иметь в виду, что когда на отраженной базе данных происходит переход на резервный ресурс, основной и зеркальный серверы меняются ролями.

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

Так как зеркальный сервер может быть расположен на большом расстоянии от основного, зеркальное отражение имеет смысл использовать в планах аварийного восстановления (DR – Disaster Recovery). Кластер может служить первой линией обороны, но что случится, если применить одновременно и кластеризацию, и зеркальное отражение? Когда происходит переход на резервный ресурс в кластере, то при наличии в конфигурации зеркального отражения следящего сервера последний становится основным на то время, пока кластеризованный сервер SQL Server возвращается в оперативный режим. Однако следует иметь в виду, что переход на резервный ресурс с нового основного сервера обратно на (кластеризованный) новый зеркальный сервер не происходит автоматически. Следовательно, лучше не включать автоматический переход на резервный ресурс для зеркально отражаемых баз данных при использовании совместно с кластером.

Аварийное восстановление – не единственная цель использования зеркального отражения. Это также полезно в ситуации, когда необходимо применить пакет обновлений или исправление на основном сервере; в этом случае можно вручную выполнить переход на резервный ресурс на зеркальный сервер. При применении пакета обновлений или исправления бывший основной сервер временно переводится в автономный режим, а завершенные транзакции, выполненные на новом основном сервере, становятся в очередь, ожидая отправления назад на новый зеркальный (бывший основной) сервер. По окончании установки пакета обновлений или исправления происходит синхронизация, в результате которой два сервера приводятся в полное соответствие. Теперь можно поменять основной и зеркальный серверы ролями. Время простоя составляет несколько секунд, потраченных на переход на резервный ресурс и обратно. Этот подход можно также использовать для миграции сервера SQL Server на другой физический сервер. Отличие только в том, что не нужно переходить обратно.

Повышение гибкости с помощью виртуального сервера

Виртуализация позволяет одновременно запускать одну или более операционных систем на одном физическом сервере. Программное обеспечение виртуализации вносит в концепцию кластеризации дополнительный уровень возможностей, позволяя кластеризовать программы. Если происходит сбой на сервере, на котором запущена ведущая операционная система, этот сервер вместе с гостевыми операционными системами переходит на резервный узел. Таким способом можно легко мигрировать гостевой сервер. Кроме того, гостевая операционная система может не поддерживать кластеризацию. Следовательно, можно запустить сервер SQL Server выпуска Workgroup Edition на гостевой операционной системе Windows Server 2003, запущенной на сервере Microsoft Virtual Server 2005 в кластере. Таким образом, фактически происходит опосредованная кластеризация сервера SQL Server выпуска Workgroup Edition (см. рис. 2 ).


Figure 2 Using a virtual server

Администратору, отвечающему за внедрение сервера SQL Server, нужно быть уверенным в непрерывной доступности сервера. Достичь этой цели помогает применение кластеризации сервера. В этой статье предложены проверенные опытом рекомендации, помогающие начать работу. Дополнительные полезные сведения можно найти на врезке «Ресурсы по кластеризации».

Ресурсы по кластеризации

Новая Отказоустойчивая кластеризация Windows Server (WSFC) представляет собой группу независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб. SQL Server 2016 поддержка экземпляров отказоустойчивого кластера Группы доступности AlwaysOn и SQL Server осуществляется с использованием служб и возможностей WSFC.

Кластер WSFC
Новая Отказоустойчивая кластеризация Windows Server (WSFC) представляет собой группу независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб.

Экземпляр отказоустойчивого кластера
Экземпляр службы Windows, управляющий ресурсом IP-адреса, ресурсом сетевого имени и дополнительными ресурсами, которые требуются для запуска приложений и служб. Клиенты могут использовать сетевое имя для доступа к ресурсам в группе аналогично использованию имени компьютера для доступу к службам на физическом сервере. Однако, поскольку экземпляр отказоустойчивого кластера является группой, для него возможен переход на другой узел без изменения базового имени или адреса.

Узел
Система Microsoft Windows Server, которая является активным или неактивным членом кластера серверов.

Ресурс кластера
Физическая или логическая сущность, которая может принадлежать узлу, которую можно переводить в режимы «в сети» и «вне сети», перемещать между узлами и которой можно управлять как объектом кластера. Ресурс кластера может принадлежать одновременно только одному узлу.

Группа ресурсов
Коллекция ресурсов кластера, управляемая как единый объект кластера. Обычно группа ресурсов содержит все ресурсы кластера, которые требуются для выполнения конкретного приложения или службы. Отработка отказа и возврат всегда выполняются для групп ресурсов.

Зависимость ресурсов
Ресурс, от которого зависит другой ресурс. Если ресурс A зависит от ресурса B, то B является зависимостью A.

Ресурс сетевого имени
Имя логического сервера, которое управляется как ресурс кластера. Ресурс сетевого имени должен использоваться с ресурсом IP-адреса.

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

Возможный владелец
Дополнительный узел, на котором может запускаться ресурс. Каждая группа ресурсов связана со списком возможных владельцев. Группы ресурсов могут выполнять переход только на узлы из списка возможных владельцев.

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

Принудительный кворум
Процесс запуска кластера несмотря на то, что на связи недостаточное количество элементов для кворума.

Отказоустойчивая кластеризация Windows Server предусматривает инфраструктурные компоненты, поддерживающие сценарии высокого уровня доступности и аварийного восстановления для таких размещенных серверных приложений, как Microsoft SQL Server и Microsoft Exchange. При отказе узла кластера или службы все службы, которые размещались на этом узле, могут автоматически или вручную переноситься на другой доступный узел в рамках процесса под названием отработка отказа.

Узлы в кластере WSFC за счет совместной работы обеспечивают следующие типы возможностей:

Читайте также:  Как списать комплектующие к компьютеру

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

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

Мониторинг исправности. Определение исправности основного узла и исправности между узлами осуществляется за счет сочетания сетевых соединений по типу тактовых импульсов и мониторинга ресурсов. Общее состояние работоспособности кластера определяется голосами кворума узлов в кластере.

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

Дополнительные сведения см. в статье Failover Clustering Overview — Windows Server (Обзор отказоустойчивой кластеризации — Windows Server).

SQL Server 2016 AlwaysOn — это новое решение высокого уровня доступности и аварийного восстановления с использованием WSFC. AlwaysOn представляет собой интегрированное, гибкое решение, повышающее доступность приложения, окупаемость вложений в оборудование и упрощающее развертывание систем высокого уровня доступности и управление ими.

Экземпляры Группы доступности AlwaysOn и экземпляры отказоустойчивого кластера AlwaysOn используют технологию платформы WSFC и регистрируют компоненты в качестве ресурсов кластера WSFC. Связанные ресурсы объединяются в группу ресурсов, которую можно сделать зависимой от других ресурсов кластера WSFC. Затем служба кластера WSFC сможет выявлять необходимость в перезапуске экземпляра SQL Server (и сигнализировать об этой необходимости), а также автоматически выполнять отработку отказа с переходом на другой серверный узел в кластере WSFC.

ВАЖНО! Чтобы воспользоваться всеми возможностями технологий SQL Server AlwaysOn, вам следует выполнить несколько связанных с WSFC предварительных требований.

Высокий уровень доступности на уровне экземпляра с помощью экземпляров отказоустойчивого кластера AlwaysOn

Экземпляр отказоустойчивого кластера (FCI) AlwaysOn представляет собой экземпляр SQL Server, установленный на нескольких узлах в кластере WSFC. Этот тип экземпляра имеет зависимости ресурсов от общего дискового хранилища (через Fibre Channel или iSCSI SAN) и от имени виртуальной сети. Имя виртуальной сети имеет зависимость ресурсов от одного или нескольких виртуальных IP-адресов, каждый в отдельной подсети. Служба SQL Server и служба агента SQL Server регистрируются в качестве ресурсов, и обе службы становятся зависимыми от виртуального ресурса сетевого имени.

В случае отработки отказа служба WSFC переносит владение ресурсов экземпляра на указанный узел отработки отказа. Затем экземпляр SQL Server перезапускается на узле отработки отказа и выполняется обычное восстановление баз данных. В любой момент времени FCI и базовые ресурсы могут размещаться только на одном узле в кластере.

ПРИМЕЧАНИЕ. Экземпляру отказоустойчивого кластера AlwaysOn требуется симметричное общее дисковое хранилище, например сеть хранения данных (SAN) или общая папка SMB. Тома общего дискового хранилища должны быть доступны всем потенциальным узлам отработки отказа в кластере WSFC.

Высокий уровень доступности на уровне баз данных с Группы доступности AlwaysOn

Группа доступности — это набор пользовательских баз данных, для которых отработка отказа выполняется одновременно. Группа доступности состоит из первичной реплики доступности и от одной до четырех вторичных реплик, которые поддерживаются за счет перемещения данных на основании журнала SQL Server для обеспечения защиты данных, не требующей общего хранилища. Каждая реплика размещается на экземпляре SQL Server в отдельном узле кластера WSFC. Группа доступности и соответствующее имя виртуальной сети регистрируются как ресурсы в кластере WSFC.

Прослушиватель группы доступности на узле первичной реплики отвечает на входящие клиентские запросы на подключение к имени виртуальной сети и в зависимости от атрибутов в строке подключения перенаправляет каждый запрос в соответствующий экземпляр SQL Server .

При отработке отказа вместо переноса владения общих физических ресурсов на другой узел WSFC используется для перенастройки вторичной реплики на другом экземпляре SQL Server в первичную реплику группы доступности. Затем ресурс виртуального сетевого имени группы доступности переводится на этот экземпляр.

Первичная реплика баз данных группы доступности одновременно может размещаться только на одном экземпляре SQL Server, все связанные вторичные реплики должны находиться на отдельном экземпляре, и каждый экземпляр должен находиться на отдельном физическом узле.

ПРИМЕЧАНИЕ. Группы доступности AlwaysOn не требует развертывания экземпляра отказоустойчивого кластера или использования симметричного общего хранилища (SAN или SMB).

Экземпляр отказоустойчивого кластера (FCI) может использоваться совместно с группой доступности для повышения доступности реплики доступности. Однако во избежание соперничества в кластере WSFC автоматический переход на другой ресурс группы доступности не поддерживается для реплики доступности, размещенной в FCI.

Высокий уровень доступности для решения AlwaysOn достигается за счет упреждающего мониторинга работоспособности физических и логических ресурсов кластера WSFC, а также за счет автоматического перехода на другой ресурс с переходом на дублирующее оборудование и его перенастройкой. Системный администратор также может запустить переход на другой ресурс вручную для группы доступности или экземпляра SQL Server для перехода с одного узла на другой.

Политики отработки отказа для узлов, экземпляров отказоустойчивого кластера и групп доступности

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

Отработка отказа реплики группы доступности не влияет на базовый экземпляр SQL Server . При отработке отказа экземпляра отказоустойчивого кластера вместе с этим экземпляром перемещаются размещенные реплики группы доступности.

Определение исправности ресурсов WSFC

Все ресурсы на узле кластера WSFC могут сообщать о своем состоянии и исправности периодически или по запросу. Об отказе ресурса могут говорить различные обстоятельства, например неисправность электропитания, ошибки дисков или памяти, ошибки в сети, неотвечающие службы.

Ресурсы кластера WSFC, например сети, хранилища и службы, можно делать зависимыми друг от друга. Совокупная исправность ресурса определяется путем последовательного суммирования его работоспособности с исправностью каждого из зависимых ресурсов.

Определение исправности между узлами WSFC и определение голосов в кворуме

Все узлы в кластере WSFC участвуют в периодической передаче тактового импульса, сообщающего состояние исправности узла другим узлам. Неотвечающие узлы считаются неисправными.

Набор узлов кворума — это большинство узлов с правом голоса и следящих объектов в кластере WSFC. Общая исправность и состояние кластера WSFC определяется периодическим голосованием с кворумом. Наличие кворума означает, что кластер работоспособен и может обеспечивать отказоустойчивость на уровне узла.

Режим кворума настраивается на уровне кластера WSFC, который определяет методику голосования кворума, а также момент выполнения автоматического перехода на другой ресурс или перевода кластера в режим «вне сети».

СОВЕТ. Рекомендуется, чтобы число голосов кворума в кластере WSFC всегда было нечетным. По соображениям голосования кворума нет необходимости устанавливать SQL Server на всех узлах в кластере. Дополнительный сервер может выступать в качестве члена кворума, либо модель кворума WSFC можно настроить для использования удаленной общей папки в качестве решающего голоса.

Аварийное восстановление через принудительный кворум

В зависимости от принятых методов работы и конфигурации кластера WSFC можно использовать как автоматический, так и ручной переход на другой ресурс, при этом решение SQL Server AlwaysOn остается всегда надежным и отказоустойчивым. Однако если кворуму узлов с правом голоса в кластере WSFC не удается связаться друг с другом либо если кластеру WSFC по другим причинам не удается проверить исправность, то кластер WSFC может перейти в режим «вне сети».

При переходе кластера WSFC в автономный режим из-за неожиданной аварии или по причине постоянно возникающего сбоя в работе оборудования или ошибки связи требуется вмешательство администратора для принудительного создания кворума и переключения работоспособных кластеров обратно в режим "в сети" в неотказоустойчивой конфигурации.

После этого будет необходимо также предпринять ряд действий по перенастройке кластера WSFC, восстановлению затронутых реплик баз данных и повторному созданию нового кворума.

Между функциями и компонентами SQL Server AlwaysOn и WSFC существуют связи нескольких уровней.

Группы доступности AlwaysOn размещаются в экземплярах SQL Server.
Клиентский запрос с указанием логического сетевого имени прослушивателя группы доступности для подключения к первичной или базе данных-получателю направляется на соответствующее сетевое имя экземпляра базового экземпляра SQL Server или экземпляра отказоустойчивого кластера SQL Server.

Экземпляры SQL Server активно размещаются на одном узле.
Если имеется изолированный экземпляр SQL Server, то он всегда находится на отдельном узле со статическим сетевым именем экземпляра. Экземпляр отказоустойчивого кластера SQL Server (если он есть) активен на одном из нескольких возможных узлов отработки отказа с единым виртуальным сетевым именем экземпляра.

Узлы являются членами кластера WSFC.
Метаданные и состояние конфигурации WSFC для всех узлов сохраняются на каждом узле. Каждый сервер может предоставлять тома асимметричного хранения или общего хранения (SAN) для пользовательских и системных баз данных. Каждый сервер имеет по крайней мере один физический сетевой интерфейс в одной или нескольких IP-подсетях.

Служба WSFC контролирует исправность группы серверов и управляет их конфигурацией.
Служба отказоустойчивого кластера (WSFC) распространяет изменения в метаданных и состоянии конфигурации WSFC во всех узлах кластера. Частичные метаданные и состояние могут храниться в удаленной общей папке следящего сервера кворума WSFC. Несколько активных узлов или следящих экземпляров образуют кворум для голосования по исправности кластера WSFC.

Группы доступности AlwaysOn — это подразделы кластера WSFC.
При удалении и повторном создании кластера WSFC необходимо отключить и повторно включить функцию Группы доступности AlwaysOn на каждом экземпляре сервера, на котором была включена функция Группы доступности AlwaysOn в исходном кластере WSFC. Дополнительные сведения см. в разделе Включение и отключение групп доступности AlwaysOn (SQL Server).

Ссылка на основную публикацию
Карта с определением координат широты и долготы
Онлайн сервис определения координат на карте России. Удобный поиск GPS координат (широта, долгота) по адресу в России, определение местоположения по...
Какие российские платежные системы
Международных платежных систем не так много. Но они дополняют друг друга. А благодаря своей универсальности их сервис позволяет переводить деньги...
Какие самсунги поддерживают беспроводную зарядку
Обращаем Ваше внимание на то, что данный интернет-сайт и его содержимое носят исключительно информационный характер и ни при каких условиях...
Карта судов в порту находка
Автоматический поиск расположения судна в море основывается на данных поступающих с АИС. Текущее положение судна, отбытие из порта и прибытие...
Adblock detector