Планирането и внедряването на план за висока наличност и възстановяване след бедствие, който отговаря на всички споразумения за ниво на обслужване, е нетривиално начинание и изисква много ясно разбиране на силните и слабите страни на SQL Server. Когато съпоставяме изискванията с комбинация от функции, някои от критичните детайли може да бъдат премълчавани и в тази публикация ще разгледам няколко често срещани изкривявания и лоши предположения, които могат да се промъкнат в решение – в крайна сметка да ни накара да пропуснем целта върху нашата точка на възстановяване и целите за времето за възстановяване. Някои от примерите за изкривявания или самозаблуди, които описвам тук, могат да бъдат обобщени за различни характеристики, а някои са специфични за дадена функция.
„Тествахме нашия план за възстановяване при бедствия, когато стартирахме нашия проект за първи път и знаем, че ще работи“
Работил съм с клиенти, които наистина са получили „правилния“ подход за възстановяване при бедствия – веднъж. Но след като всички се почувстваха уверени в ефикасността на решението, повече не бяха извършвани други упражнения за възстановяване след бедствие. Разбира се – междувременно нивото на данни и приложението продължават да се променят с течение на времето. Тези промени въвеждат нови обекти и процеси, които са критични за приложението. И дори всичко да остане статично след стартирането, все пак трябва да отчитате текучеството на персонала и различните набори от умения. Може ли днешният персонал да изпълни успешно упражнение за възстановяване след бедствие? И дори най-добрият персонал се нуждае от постоянна практика.
„Няма да имаме загуба на данни, защото използваме синхронно огледално копиране на база данни“
Да приемем, че използвате синхронно дублиране на база данни между два екземпляра на SQL Server, като всеки екземпляр е в отделен център за данни. В този пример приемете, че латентността на транзакцията е приемлива, въпреки че това е синхронна сесия за отразяване на база данни с няколко мили между центровете за данни. Нямате свидетел в микса, защото искате да контролирате ръчно преминаването при отказ на огледало на базата данни.
Сега да кажем, че вашият център за данни за възстановяване при бедствия изчезва - но основният ви център за данни все още е наличен. Вашата основна база данни е изключена от огледалната база данни, но все още приема връзки и модификации на данни. Какво ще кажете за изискването „без загуба на данни“ сега? Ако транзакциите се изпълняват срещу прекъснатия принципал за още един час, какъв е вашият план, ако основният център за данни също е загубен?
„Собственикът на нашия бизнес казва, че можем да загубим до 12 часа данни“
Важно е да зададете някои въпроси повече от веднъж и на повече от един човек в една организация. Ако някой ви каже, че „12 часа загуба на данни е приемливо“ – попитайте го отново или го попитайте какви биха били последствията от тази загуба на данни. Попитайте и други хора. Може да ви предложат много по-строги изисквания. Открих, че целите на точките за възстановяване изискват известни преговори и повече от няколко обмислени, преднамерени дискусии.
„Използваме [групи за дублиране на база данни или наличност] и затова сме покрити за това, от което се нуждаем в случай на бедствие“
Групите за дублиране на база данни и наличност със сигурност могат да се използват за защита на ниво база данни, но какво да кажем за всичко останало? Какво ще кажете за вашите входове? SSIS пакети? Работни места? Бази данни на модела за непълно възстановяване? Свързани сървъри?
„Използваме функцията на SQL Server XYZ, така че няма да загубим транзакции по време на полет“
Не, съжелявам. Въпреки че някои функции позволяват прозрачно пренасочване, това не е същото като запазване и запазване на отворени транзакции по време на отказ. Нито една функция на SQL Server не предоставя тази функционалност днес.
„Екипът, поддържащ нивото на данни за това приложение, мрази функцията на SQL Server XYZ, но ние продължаваме напред с нея, защото това ни беше препоръчано от външен консултант“
Макар че би било хубаво хората да не развиват специфични пристрастия около функциите в SQL Server, това често не е така. Ако се опитате да наложите решения на персонал, който не е на борда с тях, рискувате от предварително определен провал. Като част от HA/DR упражненията, с които съм помагал в миналото, винаги ми е интересно да чуя за миналия опит на хората със специфични функции. Например, някои компании използват много добре стотици случаи на отказен клъстер – докато други ги избягват поради лош опит от предишни версии. Когато планирате решение, не можете да пренебрегвате историята или предразположенията на персонала, който в крайна сметка ще бъде отговорен за внедряването и поддръжката на препоръчаното решение.
„Като DBA решавам коя HA/DR технология да използвам за нивото на данни, така че ще използваме групи за наличност напред“
Администраторът на база данни може потенциално да настрои огледално отразяване на база данни с малко или никакво участие с други екипи. Сега с групите за наличност, дори ако администраторът на базата данни може да направи всичко сам, може да е неразумно да го правят. В крайна сметка – ако разгръщате групи за наличност за целите на възстановяване след бедствие, вие ще искате всички, участващи в операция за възстановяване след бедствие, да са наясно с вашето решение и изискванията, необходими за успешното връщане онлайн и възстановяване на данни. С групите за наличност ще трябва да помислите за отказния клъстер на Windows Server, конфигурациите на кворума, гласовете на възли, слушателя на групата за наличност и други. Ако имате нужда от други хора, които да улеснят решението, уверете се, че те участват в първоначалната препоръка.
„Използваме групи за наличност, за да можем да имаме наличност само за четене в случай на прекъсване на нашата реплика за четене и запис“
Това е само един пример за сценарий „какво, ако“. С всяка реализация на функционалност, вие ще искате да си представите различните начини, по които може да възникне повреда – и след това не забравяйте да го тествате, за да се уверите, че вашите изисквания все още се изпълняват. Например – ако смятате, че асинхронните реплики само за четене на вашата група за наличност на SQL Server 2012 ще бъдат налични, когато репликата за четене-запис не е налична, ще бъдете неприятно изненадани да видите Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections съобщение в производството.
„Тествахме функцията на SQL Server XYZ и преминаването при отказ беше бързо, така че установихме, че можем лесно да постигнем целите си за времето за възстановяване“
Да приемем, че сте решили да използвате огледално копиране на база данни за висока наличност на ниво потребителска база данни. Искате бързо преминаване при отказ (измерено в секунди) и наистина виждате бързо преминаване при отказ по време на тестване. Но дали беше реалистичен тест? Налагахте ли значително натоварване? В примера с огледално копиране на база данни, най-дългата част от вашата операция за преодоляване на срив може да бъде за операциите за повторно изпълнение. Ако не управлявате реалистични натоварвания, тогава не можете наистина да кажете, че преодоляването на срива всъщност ще бъде „бързо“.
„Ако имаме бедствие и трябва да спасим и съгласуваме данните, ще го разберем, когато му дойде времето“
Това е трудно. Да приемем, че имате бедствие и трябва да направите своя вторичен център за данни оперативен. Решавате да форсирате услугата за най-критичните бази данни във вторичния център за данни и сега имате разделение в линията на модификациите на данни (някои несъгласувани редове в основния център за данни и сега нови модификации във вторичния център за данни). В крайна сметка вашият основен център за данни е включен онлайн – но сега имате данни, които трябва да бъдат спасени и съгласувани, преди да можете да възстановите цялостното решение за HA/DR. Какво правиш? Какво можеш да направиш? Тази дискусия рядко е лесна за провеждане и може да зависи от няколко фактора, като например софтуерните пакети, които сте закупили, сложността на нивото на данните и инструментите за конвергенция на данни, с които разполагате. Всъщност дискусията обикновено е толкова трудна, че хората изобщо я нямат. Но ако данните са достатъчно критични, за да сте създали вторичен център за данни, тогава ключова част от дискусията трябва да включва как най-добре да се спасят данните и също така да се съгласуват след като е настъпило бедствие.
Резюме
Тази статия включва само няколко примера за това как можем да се заблуждаваме, че едно решение напълно отговаря на техните изисквания. Макар че е от човешката природа да правим това – когато става въпрос за загуба на данни и непрекъснатост на бизнеса, работата ни ще зависи от това да бъдем по-агресивни в тестването на собствените си вярвания и предположения.
