Когато сървърите не работят, това може да доведе до прекъсвания на вашите бизнес цели и да доведе до загуба на приходи. Например, една авиокомпания може да не може да резервира полети за клиенти, ако екземпляри и бази данни не са налични. Системите могат да се провалят поради различни причини, като пожар, човешки грешки, компютърни повреди, повреди на дискове и програмни грешки.
За да се избегнат смущения и да се гарантира, че има приемственост в бизнес услугите, е изключително важно да има стратегии за висока наличност (HA) и за възстановяване при бедствия (DR). HA и DR често се обсъждат заедно. HA се занимава с намаляването на времето на престой на сървъра, доколкото е възможно, но тъй като никоя система не е перфектна, DR се фокусира върху процеса на използване на резервния носител за възстановяване на загубени данни в случай, че системата на базата данни се повреди.
AlwaysOn е марка/маркетингов термин, използван от SQL Server 2012 за описание на подобрените HADR функции на Microsoft. Преди AlwaysOn, механизмът на базата данни поддържаше други, вградени собствени решения, като огледално копиране на база данни, отказен клъстер и доставка на регистрационни файлове. Въпреки това, всяка от тези техники идва с предимства и ограничения. Често, в зависимост от целите си, организацията трябваше да комбинира множество методи заедно, за да постигне желана HADR стратегия.
Функциите на AlwaysOn бяха въведени, така че не е нужно да се справяте с допълнително време и ресурси за внедряване и въвеждане на сложност при внедряването, за да отчетете дублирането както на сървъра, така и на базата данни, да се сблъскате с проблеми с мащабирането или да имате хардуер в режим на готовност, който не се използва ефективно. Тези функции удобно съчетават много от старите практики заедно и подобряват областите, в които не са достигнали. За да разберете наистина стойността на предложенията на AlwaysOn, важно е да се преразгледат първоначалните основополагащи концепции за това как механизмът на базата данни е осигурявал HADR на системата в миналото.
Отражение на базата данни
Резервирането на базата данни може да бъде постигнато чрез огледално копиране. Например, можете да имате генериращо приходи клиентско приложение, което позволява на учениците да поръчват учебници онлайн. Клиент избира своята покупка и заявките се правят в базата данни на PsychologyBooks в задния край. В случай на бедствие, което прави базата данни PsychologyBooks недостъпна, ученикът няма да може да изпълни поръчката си.
За да избегнете това смущение, можете да разполагате с главен екземпляр, разгърнат в производството, който съдържа базата данни PsychologyBooks и да имате допълнително копие на тази база данни PsychologyBooks на огледален сървър в режим на готовност. Клиентските приложения могат да се свържат отново с огледалното копие, вместо да изпитват прекъсване и да трябва да чакат възстановяването да приключи на основното. Копието е в крак с промените, направени в оригинала, като получава регистрационни файлове на транзакциите и след това повтаря тези записани промени.
Огледалните сесии могат да работят в различни режими в зависимост от производителността или оправданията за висока безопасност. Удобно е, че автоматичното преминаване на отказ се поддържа, когато сесията за огледално отразяване работи в синхронен режим с висока безопасност и е установен консенсус за кворум с наличието на допълнителен сървър-свидетел.
Въпреки предимствата на огледалното копиране, то не успява, защото осигурява само резервиране на база данни, а не резервиране на сървъра. Това означава, че ако основният екземпляр на сървъра изпадне, и двата екземпляра ще се свалят и няма да има значение, че има резервно копие на данните на ниво база данни. Режимът на готовност не поддържа потребителски операции и ще са необходими моментни снимки, за да получите копие само за четене на данните в огледалния екземпляр. Базата данни е защитена, но обектите на ниво сървър, като членство в ролята на сървъра, информация за вход и задачи на агент, не са.
Например, ако имаше голям маркетингов екип и всеки член имаше свои собствени данни за вход, те ще трябва да преминат през процеса на пресъздаване на данни за влизане за всеки човек отново. Когато възникне отказ, то е на база независима база данни, а не като група.
Клъстериране при отказ
Клъстерирането при отказ предлага резервиране на ниво потребителски модел и осигурява защита от повреди на хардуера и операционната система. Например, да речем, че възел в Queen Anne се запалва, причинявайки повреда на оборудването. Целият екземпляр – който включва обекти на ниво екземпляр, като данни за влизане или конкретни работни места, които са създадени за изпълнение на конкретни задачи – ще бъде защитен и може автоматично да се рестартира на друг възел, принадлежащ към клъстера. Клиентските приложения и услуги ще продължат да бъдат достъпни за клиентите.
Горният сценарий работи, защото съхранението се споделя между излишни физически сървъри в група за отказоустойчив клъстер на Windows Server (WSFC). И ОС, и SQL Server работят заедно, така че само един възел притежава групата ресурси на WSFC в даден момент.
За съжаление, с общо хранилище, това решение не осигурява резервирането на базата данни, което предоставяше по-ранната стратегия за огледално отразяване. Наличието на споделено хранилище създава риск, защото води до една точка на отказ. Например външните дискове може да съдържат единственото копие на важната база данни PsychologyBooks и въпреки успешното прехвърляне на екземпляра към възела Ballard, все още ще има прекъсване на бизнес целите, ако единственият компонент за съхранение е компрометиран. Клъстерирането при отказ също така предлага ограничения по отношение на мащабируемостта, тъй като клиентските приложения не са в състояние да се справят с нарастващо количество работа, която се разширява по-далеч от клъстера.
Изпращане на дневници
Друг метод за постигане на дублиране на базата данни е чрез доставка на дневници. Регистрите на транзакциите се архивират на основния сървър и се изпращат до един или много вторични сървъри, за да бъдат възстановени. За разлика от огледалното копиране, вторичната(ите) база(и) могат да отговарят на условията за дейност само за четене, а честотата на изпращане на регистрационни файлове може да бъде конфигурирана за различни интервали. Има предимство в производителността в сценарии, при които вторичните бази данни не трябва непременно да бъдат синхронизирани с първичната база данни в реално време.
Например, пускането на статистически обобщен отчет в края на нощта, за да видите какви книги по психология се продават през деня, не изисква базата данни за копиране да бъде точно в синхрон с основната база данни. Активността с интензивно четене поставя заключвания върху обекти на база данни и може да увеличи времето за изчакване. Следователно, изпълняването на отчети на вторичен сървър би облекчило търсенето на натоварване на основния сървър, генериращ приходи.
Недостатъкът е, че доставката на регистрационни файлове не поддържа автоматично преминаване при отказ. Следователно, ако изходният сървър се повреди, базата данни трябва да бъде възстановена ръчно. Подобно на огледалното копиране, доставката на журнали не осигурява резервиране на сървъра и е решение на ниво база данни.
Разбиране на AlwaysOn
Всяка от старите технологии има своите предимства и компромиси. Но внедряването на персонализирано HADR решение може бързо да стане сложно и да изисква повече управление, тъй като тези различни стратегии са произволно смесени и съчетани заедно, за да отговорят на нуждите на бизнеса. Поради това бяха въведени функциите AlwaysOn и предоставят подобрена, вече комбинирана версия на предишни стратегии.
SQL Server предлага две функции:AlwaysOn Availability Groups (AG) и AlwaysOn Failover Cluster Instances (FCI). И двете изискват внедряване на отказоустойчив клъстер на Windows Server (WSFC).
AG е група от бази данни, които ще се преодоляват заедно. Ще ви трябват няколко излишни физически възли с инсталиран екземпляр на SQL Server на всеки от възлите, за да хоствате репликите на наличността. Всяка реплика трябва да бъде на различен възел на същия WSFC. В схемата по-горе, първичната реплика се хоства на възел 01, а всички останали вторични реплики отговарят на условията за отказ, когато WSFC усети, че има проблем.
Начинът, по който вторичните реплики остават в синхрон с първичните, е чрез изпращане на регистрационни файлове на транзакциите и повторно извършване на промените. AG поддържа както асинхронен, така и синхронен режим на записване. Първичната реплика отговаря на условията за четене и запис, докато вторичните реплики отговарят на условията само за четене. Архивирането може да се извършва на вторично място.
Веднага има предимства с AlwaysOn AG. Припомнете си от по-рано, че някои от недостатъците на огледалното копиране на база данни са, че една база данни може да бъде огледална само на един вторичен сървър и че когато възникне отказ, всяка база данни се отразява независимо. С AG базите данни се правят излишни на много места, като възел 02, възел 03, възел 04 и възел 05 в примера по-горе. Поддръжката за наличност на база данни позволява до девет реплики за наличност.
Освен това, доставката на регистрационни файлове ще бъде необходима за постигане на данни само за четене на вторичния сървър. Но с AG данните само за четене вече се отчитат. Дейности с интензивно четене, като например докладване, могат да се извършват на всяка от вторичните реплики. Също така имайте предвид, че няма ограничение за споделено съхранение.
Въпреки това, AG може да се комбинира с AlwaysOn FCI, за да позволи резервиране на сървъра. FCI екземпляр може да се използва за хостване на репликите на наличността, така че обекти на ниво сървър, като данни за влизане и задачи на агент, също могат да бъдат защитени. Този подход ще изисква споделено съхранение. Въпреки това, неудобства като необходимостта от преконфигуриране за клиентските приложения ще бъдат елиминирани.
