Database
 sql >> база данни >  >> RDS >> Database

SQL Always On Availability Groups:Компютърни обекти

SQL Server Always On Availability Groups е най-новата технология на Microsoft за посрещане на нуждите от висока наличност и аварийно възстановяване на организации, които използват SQL Server. Едно голямо предимство на AlwaysOn е способността да се адресира както HA, така и DR в една реализация. Изпитахме следните основни предимства на AlwaysOn:

  1. Можем да групираме свързани бази данни като част от една група за наличност и да ги накараме да преминат при отказ заедно, в случай че това е необходимо. Това е особено полезно за приложения, които зависят от повече от една база данни, като Microsoft Office SharePoint, Microsoft Lync и Sage.

  2. Когато се сравняват екземпляри на клъстер при отказ на SQL Server, откриваме, че съхранението като единична точка на повреда е елиминирано от всеки екземпляр, който представлява реплика е назначено собствено хранилище.

  3. С AlwaysOn е възможно да конфигурирате HA и DR наведнъж. Това се постига чрез създаване на многосайтови Windows отказоустойчиви клъстери като основи на вашата AlwaysOn конфигурация. Извършването на превключване на ролята при използване на AlwaysOn е значително по-лесно, отколкото при използване на доставка на дневник на транзакциите.

Компютърни обекти

Активната директория (AD) е огромна тема и няма да задълбаваме в подробностите в тази статия. Както можете да се досетите, Active Directory е услугата за директории на Microsoft. От гледна точка на компютърна мрежа, услугата за справочници е средство, което ни позволява да регистрираме, идентифицираме и управляваме централно всички обекти в мрежата. Записите в услугите на директорията картографират имената на мрежовите устройства към съответните IP адреси и други свойства в директорията. Най-често срещаните обекти в услуга на директории (и в AD на Microsoft) са потребители и компютри. Точно както всеки потребител в домейна може да бъде регистриран и управляван от Active Directory, всеки компютър в домейна може да бъде управляван и от Active Directory. Точно както се очаква всеки потребител да има уникален акаунт в Active Directory, така и всеки компютър.

В Active Directory не всички компютърни обекти се свързват с физически компютър. Компютърният обект може да представлява физически компютър (работна станция или сървър), но може да представлява и нещо, което действа като компютър, като например представителното име за клъстер на Windows или виртуалното име за услуга на клъстер (роля). Такива представяния също са уникални в Active Directory, точно като имената на обикновените компютри.

CNO и VNO в WSFC

Когато инсталирате отказен клъстер на Windows, инсталаторът създава обект в Active Directory, наречен обект с име на компютър (CNO). Този CNO е основният обект, създаден в Active Directory за клъстера и представлява „Име на сървъра“ на целия клъстер. Впоследствие други обекти, известни като Виртуални обекти с име се създават от CNO при извършване на такива дейности като създаване на роли на клъстери, групи за наличност, или Групови слушатели за наличност . Тези CNO и VNO имат IP адреси, свързани с тях. Можете да посочите тези адреси, когато инсталирате клъстера или създавате нова роля на клъстер или слушател. За всеки клъстер, роля и слушател, които създавате, имате нужда от уникално име на компютър и уникален IP адрес. Фиг. 1 показва стъпката, по време на която задавате обекта име на клъстер и неговия IP адрес, когато конфигурирате клъстер.

Имената, които използвате при конфигуриране на клъстер, са напълно произволни. Те просто трябва да бъдат уникални. Въпреки това се препоръчва да следвате конвенциите за именуване на вашата организация за обикновени компютри, когато създавате CNO или VNO – това помага за по-лесно управление. Също така има смисъл да използвате специфичен блок от IP адреси, който ще покрие всички нужди за адресиране за целия ви клъстер – CNO и всички VNO (роли), които възнамерявате да създадете.

Фиг. 1 Съпоставяне на име към адрес в клъстер

Ключовите разрешения за домейн

DBA или системният администратор, извършващ клъстерна инсталация, трябва да има разрешение за Създаване на компютърни обекти в домейна на Active Directory. От своя страна, след като създаде обекта за име на компютър, администраторът на домейна трябва да предостави следните разрешения на обекта име на компютър, така че ролите (които водят до обекти на виртуално име) да могат успешно да бъдат създадени в клъстера:

  1. Създаване на компютърни обекти

  2. Прочетете всички свойства

Без тези разрешения е вероятно да получите съобщения за грешка, подобни на това по-долу, когато се опитвате да създадете роля (в случай на AlwaysOn FCI ) или слушател (в случай на AlwaysOn AG ):

Грешка по време на инсталацията на MS SQL Server Cluster:

Ресурсът за мрежово име на клъстера „SQL Network Name (EUK-SCCM-01)“ не успя да създаде свързания си компютърен обект в домейн „domainname.com“ поради следната причина:Невъзможност за създаване на компютърен акаунт.

Текстът за свързания код за грешка е:Достъпът е отказан.

Това съобщение за грешка се наблюдава в Event Viewer, тъй като SQL Server няма да бъде достъпен в момента. Също така ще можете да видите това, ако отидете до файловете на SQL Error Log в папката LOG, която се намира в инсталационната директория на SQL Server. Ключовата фраза е „Достъпът е отказан “.

Други изисквания

Трябва да спомена концепцията за домейн контролер. Контролер на домейн, или по-точно, набор от контролери на домейн предоставя ключови услуги за Active Directory, като регистриране на обекти и удостоверяване на потребители и компютри. За да конфигурирате успешно клъстер или AlwaysOn Listener, контролерът на домейн трябва да бъде достъпен от компютъра, на който извършвате конфигурирането. Това означава, че комуникацията от компютъра към контролера на домейна трябва да бъде отворена на редица TCP и UDP портове. Microsoft документира това много подробно в тази статия . Това може да е даденост в повечето случаи, но когато отстранявате проблеми със свързаността, помага да разберете какво всъщност е необходимо.

В предишна статия , споменах също, че е необходимо да се предоставят разрешения на CNO на клъстер при конфигуриране на кворум за споделяне на файлове.

Фиг. 2 Разрешения за споделяне на файлове

Бележка относно разделителната способност на имената

Като компютърни обекти, CNO и VNO зависят от услугата за имена на домейни, за да разрешат името, посочено при инсталиране на клъстера, създаване на роля или създаване на AlwaysOn Listener. Обикновено на клиентите се дават тези имена на компютри, за да установят връзка с клъстера. С други думи, IP адресът е прозрачен за тях, което прави конфигурирането на клиента опростено и абстрахира отказите от крайните потребители.

Фиг. 3 Свойства на слушател на AG за слушател с два IP адреса

В предишна статия споменах случай, при който този сценарий може да причини проблеми. В нашия клъстер с множество сайтове имахме един слушател за нашата група за наличност AlwaysOn. Този слушател е конфигуриран да разрешава до два IP адреса. Това е необходимо за клъстер от няколко сайта, обхващащ множество подмрежи. При такава конфигурация сървърът за имена ще върне и двата IP адреса, съпоставени със слушателя при издаване на nslookup проверка (виж фиг. 4). Въпреки това, когато се свързвате, можете да получите достъп само до един от тези IP адреси в даден момент. Cluster Manager ще покаже другия IP адрес като Офлайн (виж Фиг. 5).

Фиг. 4 Свойства на слушател на AG за слушател с два IP адреса

Фиг. 5 свойства за роля на клъстер с два IP адреса в отделни подмрежи

Това е нормално. Ако има отказ към алтернативния сайт, DNS сървърът започва да разрешава алтернативния IP адрес след няколко минути. Последствието от това е, че комуникацията на клиентите с алтернативния сайт трябва да бъде възможна. Фиг. 6 и Фиг. 7 подчертават това допълнително.

Фиг. 6 комуникационен път с първична реплика в Дакар

Нека разгледаме добре пътя, който пакетите ще преминат от клиентските компютри до клъстера. Когато първичната реплика е в Дакар, името на слушателя SQL-SVR-LNR се разрешава до IP адреса 192.168.1.20 и WFCS от своя страна насочва заявката към сървъра 192.168.1.22 (обърнете внимание, че този сървър също има свой собствен име на компютър). В случай на отказ към Найроби, комуникационният път минава през 192.168.2.20 и след това до 192.168.2.22. Изводът е, че за безпроблемно изживяване на клиентите, всички клиенти във всички центрове за данни трябва да имат разрешена комуникация на всички включени защитни стени, използващи порт 1433.

Фиг. 7 комуникационен път с първична реплика в Найроби

Заключение

Докато Windows Failover Clustering, Active Directory и услугата за имена на домейни може да са извън ролята на администратора на базата данни, струва си да имате основно разбиране за това как работят тези технологии, за да можете да изградите и отстранявате AlwaysOn Екземпляри на клъстер при отказ и групи за наличност AlwaysOn. Някои организации имат стриктно разделение на задълженията между системните администратори и администраторите на бази данни, но когато това не е така, администраторът на база данни трябва да може да обхване главата си около тези концепции на Windows, за да успее като DBA.

Препратки

  1. Преглед на групите за наличност на AlwaysOn

  2. Клъстер при отказ на Windows със SQL Server

  3. Преглед на услугата и изисквания за мрежов порт за Windows

  4. Администриране на компютърни обекти


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL АКТУАЛИЗАЦИЯ за начинаещи

  2. 10 най-добри стартиращи фирми в облака – 2018 г

  3. Проектиране на база данни за регистриране на одит

  4. Проблеми с представянето:Първата среща

  5. Apache Spark ODBC драйвер