Группы доступности AlwaysOn и задания SQL Server: «продвинутые» системы
Содержание:
1. Управление заданиями с помощью главных серверов;
2.«Продвинутые» системы (Вы читаете данный раздел);
3. Дополнительные способы аварийных переключений заданий;
4. Еще один способ работы с аварийными переключениями и активацией заданий.
В предыдущих статьях я оперировал главным образом «простыми» группами доступности, то есть решениями, состоящими из двух реплик (основная и нечитаемая вспомогательная). А это в свою очередь объясняет, почему тот код, который я использовал в тех статьях, где основное внимание уделялось либо выявлению различий в заданиях (синхронизации), размещенных на различных узлах, либо решению, на каком сервере выполнять задачу, определялся прежде всего понятием партнерского связанного сервера. Проблема, разумеется, в том, что хотя многие группы доступности будут создаваться в целях обеспечения «простой» отказоустойчивости или избыточности, я уверен, что многие группы доступности будут значительно более сложными или, скажем так, более «продвинутыми». По этой причине я хотел бы коснуться ряда проблем, с которыми вам придется столкнуться при запуске группы доступности, а также при запуске заданий агентов SQL Server в топологиях, включающих в себя более двух реплик.
В ситуациях, когда в группах доступности имеется более двух узлов — неважно, по какой причине они появляются,— отдельными вопросами, рассмотренными нами ранее, не обойтись, поскольку здесь возникает ряд других соображений. которые следует принимать во внимание. Вот на что вам стоило бы обратить внимание (порядок пунктов не принципиален).
• Резервные копии и вспомогательные реплики (когда их число превышает единицу). Это самый простой пункт — о нем мы уже упоминали. Нужно только указать предпочтения, на какой реплике вы хотели бы выполнять резервные копии, и дело сделано.
• Случаи восстановления данных. Если вы создали решения, обеспечивающие удаленную доступность, или «растянутые» системы, в которых некий центр обработки данных располагает двумя адаптерами FCI. и затем «подсоединили» свой кластер к кластеру во вспомогательном центре обработки данных (с помощью «репликации» средствами AlwaysOn), значит, вы сделали это с целью создания отказоустойчивого решения. В большинстве случаев вы тем самым попытаетесь зеркально отобразить детали настроек в одном центре обработки данных, в максимальной степени совпадающие с соответствующими показателями другого центра обработки данных. И все же, к сожалению, руководство зачастую пытается «прикрыть» один из таких центров обработки данных (и соответственно аппаратные средства) в рамках борьбы за экономию. Чаще всего эти меры не срабатывают, так что смело протестуйте против них всякий раз, когда это возможно, если только в соглашениях об уровне обслуживания нет четко выраженных положений, гарантирующих вашу защиту в случае неблагоприятной реакции, которая непременно последует. По этой причине, если вы окажетесь в таком незавидном положении, просто поймите, что в вашем случае рабочие нагрузки не должны быть идентичными на разных участках — так, чтобы некоторые задания можно было отключать или лишать доступа к отдельным элементам «инфраструктуры» и конечным точкам, которые, возможно, были бы доступны в другом центре обработки данных. Вам придется соответствующим образом осуществлять планирование (и принимать все сказанное в расчет при определении того, каким образом упомянутые обстоятельства будут влиять на стратегию. используемую вами для сохранения согласованности заданий и/или сохранения возможности их активации/деактивации по мере необходимости).
• Лицензирование. Надеюсь, что следующее соображение будет понятно без всяких разъяснений, хотя я всегда изумляюсь, насколько часто организации упускают его из виду. Итак, помните, что если вы используете программу поддержки Software Assurance, вы, в сущности, заключаете сделку из разряда «купил один продукт — второй (равный или меньший по стоимости) получаешь бесплатно». По условиям этой сделки Microsoft продает вам лицензию на SQL Server Enterprise Edition, которая обеспечит вам функционирование «основного» сервера, а также вспомогательного сервера (на аналогичной или менее мошной аппаратной платформе), который может использоваться исключительно для обеспечения аварийных переключений. Если в дополнение к этому вам требуется получать отчеты с данного сервера или ваши разработчики хотят запускать тестовые базы данных либо решать аналогичные задачи, такой лицензии вам будет недостаточно. Вместо нее потребуется получить производственную лицензию. Соответственно, когда в организациях начинают говорить о выполнении масштабных сценариев (то есть о формировании вспомогательных реплик с правами только для чтения), важно иметь в виду, что при всех достоинствах упомянутых вариантов за них приходится платить — приобретать дополнительную лицензию. Хотя нужно сказать, что в случае приобретения с гарантией Software Assurance эта лицензия, в свою очередь, тоже приобретается по схеме «купил один продукт — второй получаешь бесплатно». Речь идет об SQL Server 2014 и более новых версиях — до их появления соглашение SA не требовалась.
• Синхронизация и активация заданий. В ранее опубликованных статьях серии примеры кода и демонстрационные решения были привязаны в основном к «двухузловым группам доступности» и в значительной степени основывались на идее использования абстракций в форме двух серверов, которые в равной степени обращались друг к другу как к 'PARTNER' (через интерфейсы связанных серверов), чтобы облегчить операции взаимопроверки и сопоставления деталей, касающихся активных заданий, деталей заданий (например, является ли определение той или иной задачи на сервере А точной копией определения на сервере В) и т.д. Проблема, разумеется, состоит в том, что если вы употребляете ServerC или ServerD, эта конструкция не работает, и вы оказываетесь перед необходимостью искать другое средство обеспечения согласованности или идентичности определений заданий на серверах. Впрочем, работа с аварийными переключениями или определение того, какой сервер является активным и должен взять на себя выполнение заданий, осуществляется так же, как и раньше, и код, описанный ранее, по-прежнему функционирует в соответствии с ожиданиями. Так вот, имея в своем распоряжении предназначенные только для чтения вспомогательные серверы (для которых вы приобрели дополнительные платные лицензии, чтобы иметь возможность снять с основного сервера задачу обработки данных), вы, возможно, захотите рассмотреть варианты, позволяющие нацеливать некоторые (разумеется, предназначенные только для чтения) агенты SQL Server (для организации отчетов или для других целей) на один из вспомогательных серверов «только для чтения». И если у вас появится такое желание, выяснится, что вам требуется иной способ выявления «предпочтительного» сервера, после того как произойдет аварийное переключение и все декорации поменяются. Одно из очевидных решений в этом случае может состоять в том, чтобы вывести выполнение задания из той логики, которая определяет предпочтительную реплику при работе с резервными копиями. Во многих случаях, если вы решили перевести операции по обработке резервных копий на вспомогательный сервер, будет вполне логично выполнять здесь и предназначенные только для чтения задачи агентов SQL Server. Иначе когда в дело вступят более двух серверов, вполне вероятно, что вам придется создать механизм проверки всех серверов по имени (вместо использования слова PARTNER как псевдонима связанных серверов), и тогда вам также придется решать вопрос об определении, где именно будет выполняться этот код.
Ну, а если ваша организация специализируется исключительно на здравоохранении, то вам, конечно же, важнее не отлаженная корпоративная сеть, а качественное медицинское оборудование. Именно поэтому вам следует прямо сейчас заглянуть на сайт www.komplex-m.ru/ (http://www.komplex-m.ru/). Здесь вы сможете приобрести высококлассное мед. оборудование на максимально выгодных для себя условиях.
1. Управление заданиями с помощью главных серверов;
2.
3. Дополнительные способы аварийных переключений заданий;
4. Еще один способ работы с аварийными переключениями и активацией заданий.
В предыдущих статьях я оперировал главным образом «простыми» группами доступности, то есть решениями, состоящими из двух реплик (основная и нечитаемая вспомогательная). А это в свою очередь объясняет, почему тот код, который я использовал в тех статьях, где основное внимание уделялось либо выявлению различий в заданиях (синхронизации), размещенных на различных узлах, либо решению, на каком сервере выполнять задачу, определялся прежде всего понятием партнерского связанного сервера. Проблема, разумеется, в том, что хотя многие группы доступности будут создаваться в целях обеспечения «простой» отказоустойчивости или избыточности, я уверен, что многие группы доступности будут значительно более сложными или, скажем так, более «продвинутыми». По этой причине я хотел бы коснуться ряда проблем, с которыми вам придется столкнуться при запуске группы доступности, а также при запуске заданий агентов SQL Server в топологиях, включающих в себя более двух реплик.
Задания в сетях с развернутыми и разбросанными по ряду расположений группами доступности
В ситуациях, когда в группах доступности имеется более двух узлов — неважно, по какой причине они появляются,— отдельными вопросами, рассмотренными нами ранее, не обойтись, поскольку здесь возникает ряд других соображений. которые следует принимать во внимание. Вот на что вам стоило бы обратить внимание (порядок пунктов не принципиален).
• Резервные копии и вспомогательные реплики (когда их число превышает единицу). Это самый простой пункт — о нем мы уже упоминали. Нужно только указать предпочтения, на какой реплике вы хотели бы выполнять резервные копии, и дело сделано.
• Случаи восстановления данных. Если вы создали решения, обеспечивающие удаленную доступность, или «растянутые» системы, в которых некий центр обработки данных располагает двумя адаптерами FCI. и затем «подсоединили» свой кластер к кластеру во вспомогательном центре обработки данных (с помощью «репликации» средствами AlwaysOn), значит, вы сделали это с целью создания отказоустойчивого решения. В большинстве случаев вы тем самым попытаетесь зеркально отобразить детали настроек в одном центре обработки данных, в максимальной степени совпадающие с соответствующими показателями другого центра обработки данных. И все же, к сожалению, руководство зачастую пытается «прикрыть» один из таких центров обработки данных (и соответственно аппаратные средства) в рамках борьбы за экономию. Чаще всего эти меры не срабатывают, так что смело протестуйте против них всякий раз, когда это возможно, если только в соглашениях об уровне обслуживания нет четко выраженных положений, гарантирующих вашу защиту в случае неблагоприятной реакции, которая непременно последует. По этой причине, если вы окажетесь в таком незавидном положении, просто поймите, что в вашем случае рабочие нагрузки не должны быть идентичными на разных участках — так, чтобы некоторые задания можно было отключать или лишать доступа к отдельным элементам «инфраструктуры» и конечным точкам, которые, возможно, были бы доступны в другом центре обработки данных. Вам придется соответствующим образом осуществлять планирование (и принимать все сказанное в расчет при определении того, каким образом упомянутые обстоятельства будут влиять на стратегию. используемую вами для сохранения согласованности заданий и/или сохранения возможности их активации/деактивации по мере необходимости).
• Лицензирование. Надеюсь, что следующее соображение будет понятно без всяких разъяснений, хотя я всегда изумляюсь, насколько часто организации упускают его из виду. Итак, помните, что если вы используете программу поддержки Software Assurance, вы, в сущности, заключаете сделку из разряда «купил один продукт — второй (равный или меньший по стоимости) получаешь бесплатно». По условиям этой сделки Microsoft продает вам лицензию на SQL Server Enterprise Edition, которая обеспечит вам функционирование «основного» сервера, а также вспомогательного сервера (на аналогичной или менее мошной аппаратной платформе), который может использоваться исключительно для обеспечения аварийных переключений. Если в дополнение к этому вам требуется получать отчеты с данного сервера или ваши разработчики хотят запускать тестовые базы данных либо решать аналогичные задачи, такой лицензии вам будет недостаточно. Вместо нее потребуется получить производственную лицензию. Соответственно, когда в организациях начинают говорить о выполнении масштабных сценариев (то есть о формировании вспомогательных реплик с правами только для чтения), важно иметь в виду, что при всех достоинствах упомянутых вариантов за них приходится платить — приобретать дополнительную лицензию. Хотя нужно сказать, что в случае приобретения с гарантией Software Assurance эта лицензия, в свою очередь, тоже приобретается по схеме «купил один продукт — второй получаешь бесплатно». Речь идет об SQL Server 2014 и более новых версиях — до их появления соглашение SA не требовалась.
• Синхронизация и активация заданий. В ранее опубликованных статьях серии примеры кода и демонстрационные решения были привязаны в основном к «двухузловым группам доступности» и в значительной степени основывались на идее использования абстракций в форме двух серверов, которые в равной степени обращались друг к другу как к 'PARTNER' (через интерфейсы связанных серверов), чтобы облегчить операции взаимопроверки и сопоставления деталей, касающихся активных заданий, деталей заданий (например, является ли определение той или иной задачи на сервере А точной копией определения на сервере В) и т.д. Проблема, разумеется, состоит в том, что если вы употребляете ServerC или ServerD, эта конструкция не работает, и вы оказываетесь перед необходимостью искать другое средство обеспечения согласованности или идентичности определений заданий на серверах. Впрочем, работа с аварийными переключениями или определение того, какой сервер является активным и должен взять на себя выполнение заданий, осуществляется так же, как и раньше, и код, описанный ранее, по-прежнему функционирует в соответствии с ожиданиями. Так вот, имея в своем распоряжении предназначенные только для чтения вспомогательные серверы (для которых вы приобрели дополнительные платные лицензии, чтобы иметь возможность снять с основного сервера задачу обработки данных), вы, возможно, захотите рассмотреть варианты, позволяющие нацеливать некоторые (разумеется, предназначенные только для чтения) агенты SQL Server (для организации отчетов или для других целей) на один из вспомогательных серверов «только для чтения». И если у вас появится такое желание, выяснится, что вам требуется иной способ выявления «предпочтительного» сервера, после того как произойдет аварийное переключение и все декорации поменяются. Одно из очевидных решений в этом случае может состоять в том, чтобы вывести выполнение задания из той логики, которая определяет предпочтительную реплику при работе с резервными копиями. Во многих случаях, если вы решили перевести операции по обработке резервных копий на вспомогательный сервер, будет вполне логично выполнять здесь и предназначенные только для чтения задачи агентов SQL Server. Иначе когда в дело вступят более двух серверов, вполне вероятно, что вам придется создать механизм проверки всех серверов по имени (вместо использования слова PARTNER как псевдонима связанных серверов), и тогда вам также придется решать вопрос об определении, где именно будет выполняться этот код.
Ну, а если ваша организация специализируется исключительно на здравоохранении, то вам, конечно же, важнее не отлаженная корпоративная сеть, а качественное медицинское оборудование. Именно поэтому вам следует прямо сейчас заглянуть на сайт www.komplex-m.ru/ (http://www.komplex-m.ru/). Здесь вы сможете приобрести высококлассное мед. оборудование на максимально выгодных для себя условиях.
