[Източник] Висока наличност в SQL Server (1) ---- преглед на високата наличност

От SQL Server 2005 насам Microsoft предоставя различни технологии с висока наличност за намаляване на прекъсванията и повишаване на защитата на бизнес данните, а с непрекъснатото издание на SQL Server 2008, SQL Server 2008 R2 и SQL Server 2012, в SQL Server има много технологии с висока наличност, които отговарят на различни сценарии.

    Преди да започна тази статия, ще започна с кратък преглед на това какво определя коя технология с висока наличност да се използва.

    Много компании искат всички или част от данните си да са високо достъпни, като например сайтове за онлайн пазаруване, онлайн продуктовите бази данни трябва да са онлайн 24/7, в противен случай в силно конкурентна пазарна среда прекъсването означава загуба на клиенти и приходи. Например, в кол център, който разчита на SQL Server, ако базата данни спре, всички обаждащи се могат само да седят и да отговарят на клиента "Съжалявам, системна повреда", което също е неприемливо.

    Разбира се, в идеалния свят всички критични данни ще са онлайн по всяко време, но в реалния свят ще има различни причини базата данни да е недостъпна, тъй като е невъзможно да се предвиди времето и формата на бедствието, необходимо е предварително да се вземат мерки за предотвратяване на различни спешни ситуации, затова SQL Server предоставя разнообразие от технологии с висока наличност, които основно включват: клъстериране, репликация, огледало, доставка на логове, групи за наличност AlwaysOn и други като архивиране и възстановяване на файлови групи, Едноинстанционни технологии с висока наличност, като например онлайн индекси за възстановяване. Използването на технология с висока наличност не означава избор на позната технология за директна употреба, а за цялостно разглеждане на бизнеса и технологията. Защото няма единна технология, която да може да изпълнява всички функции. Как да приемете тези технологии според вашия конкретен бизнес и бюджет е т.нар. стратегия за висока наличност.

При проектиране на стратегия за висока наличност, първо трябва да вземете предвид следните фактори:

• RTO (Цел за възстановяване време) – тоест целенасочено време за възстановяване, означава колко време за прекъсване е позволено, обикновено изразено с няколко 9-ки, например 99.999% наличност означава не повече от 5 минути престой годишно, 99.99% наличност означава не повече от 52.5 минути престой годишно, а 99.9% наличност означава не повече от 8.75 часа престой годишно. Струва си да се отбележи, че методът на изчисление на RTO взема предвид дали системата е 24*365 или само от 6 сутринта до 21:00 и т.н. Трябва също да обърнете внимание дали прозорецът за поддръжка се брои за време на престой, и е по-лесно да се постигне по-висока наличност, ако поддръжката и обновяването на базата данни са разрешени по време на периода на поддръжка.
• RPO (Цел на точка за възстановяване) – Известен още като цел за точка на възстановяване, означава колко загуба на данни е позволена. Обикновено, стига да направите добро архивиране, лесно можете да постигнете нулева загуба на данни. Но когато настъпи бедствие, в зависимост от степента на повреда в базата данни, времето, необходимо за възстановяване на данни от архив, ще доведе до недостъпност на базата данни, което ще повлияе на внедряването на RTO. Ранен и по-известен пример е банкова система в Европа и Съединените щати, при която RPO има само пълни резервни копия и логове в системата, пълни резервни копия на всеки 3 месеца, архивиране на всеки 15 минути, когато настъпи бедствие, само чрез пълни резервни копия и архивиране на логове могат да възстановят данните, така че въпреки че няма загуба на данни, възстановяването отнема два пълни дни, банковата система беше недостъпна за 2 дни, така че голям брой клиенти бяха загубени. Друг противоположен пример е местен онлайн видео сайт, който използва SQL Server като релационна база данни за бекенд, фронтендът използва No-SQL и редовно импортира No-SQL данни в релационната база данни като резервно копие.
  

    Бюджет – RTO и RPO се наричат колективно SLA (Споразумения за ниво на обслужване), и при проектиране на стратегия за висока наличност трябва да измерите колко добре отговаряте на SLA според вашия бизнес, в зависимост от бюджета ви и да измерите разходите на различните SLA в случай на провал. Общо взето, трудно е да се постигнат високи SLA с ограничен бюджет, и дори ако високите SLA се постигнат чрез сложни архитектури, сложните архитектури означават и високи оперативни и поддържащи разходи, затова е необходимо да се избере правилната технология в рамките на бюджета, за да се покрият SLA.

Следователно, като цяло, голямата рамка за висока наличност може да се определи чрез няколко въпроса за приемане на поръчки:

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

• Студено архивиране: Резервният сървър е конфигуриран да приема данните на основния сървър и при повреда ръчно да възстанови данните в основната база данни или да преконфигурира низа за връзка или разрешенията на програмата, за да активира резервната база данни онлайн.
• Топло архивиране: Основните данни от сървъра непрекъснато предават логове към резервния сървър (на нередовни интервали – 15 минути, 30 минути, 1 минута и т.н.), по този начин основният сървър към резервния сървър обикновено се обновява асинхронно, така че данните на основния и резервния сървър не могат да бъдат гарантирани. Освен това тази схема обикновено не прилага автоматично наблюдение на повреди и превключване на отказ.
• Горещо архивиране: Данните на основния сървър се синхронизират автоматично на сървъра за резервно копие, като в повечето случаи се включва автоматично наблюдение на грешки и превключване на резервни копия, а консистентността на данните между основния сървър и резервния сървър може да бъде гарантирана.
  

    От студени към топли резервни копия, цените скачат драстично.

    Функциите за висока наличност, поддържани в SQL Server, са тясно свързани с версията, а Enterprise изданието поддържа всички функции с висока наличност, включително:

• Failover клъстер
• l Изображение на базата данни
• l Предаване на транзакционен лог
• I Снимки от базата данни
• Високи ъпгрейди на наличност
• I Памет за горещо зареждане
• l Онлайн индексиращи операции
• l Базата данни частично онлайн (възстановяват се само главна група или група главни файлове и допълнителни NDF файлове)
  

    За конкретни версии на кои функции с висока наличност, вижте:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxСтрува си да се отбележи, че безплатната Express версия може да служи като сървър за свидетели за огледално огледало на базата данни, което води до спестяване на разходи.

Failover клъстер

    Failover клъстерите осигуряват висока наличност за цялата SQL Server инстанция, което означава, че SQL Server инстанция на възел в клъстера се прехвърля към други възли в клъстера поради хардуерни грешки, грешки в операционната система и др. Високата наличност се постига чрез споделяне на един или повече дискове от няколко сървъра (възли), а клъстерите за превключване на резерви се появяват в мрежата по същия начин като при един компютър, но с високи характеристики на наличност. Важно е да се отбележи, че тъй като failover клъстерите са базирани на споделени дискове, има една точка на отказ на диска, затова допълнителни защити като репликация на SAN трябва да бъдат внедрени на ниво диск. Най-често срещаният failover клъстер е клъстер с два възела, включително главния и подчинен.

Предаване на транзакционен лог

    Доставката на транзакционен лог осигурява защита на ниво база данни с висока наличност. Логването се използва за поддържане на една или повече резервни бази данни (наречени "вторични бази данни") на съответната производствена база данни (наречена "първична база данни"). Преди да настъпи превключване, вторичната база данни трябва да бъде напълно обновена чрез ръчно прилагане на всички невъзстановени архивни копия на логове. Доставката на логове има гъвкавостта да поддържа множество резервни бази данни. Ако са необходими няколко алтернативни бази данни, доставката на логове може да се използва отделно или като допълнение към огледалото на базата данни. Когато тези решения се използват заедно, основната база данни на текущата конфигурация за огледално отразяване на базата данни е и основната база данни на текущата конфигурация за доставка на логове.

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

Огледално отразяване на база данни

    Огледалото на база данни всъщност е софтуерно решение, което осигурява защита на ниво база данни, осигурявайки почти мигновено превключване за подобряване на наличността на базата данни. Огледалото на базата данни може да се използва за поддържане на една резервна база данни (или "огледална база данни") за съответната производствена база данни (наречена "основна база данни").
Тъй като огледалната база данни винаги е в състояние на възстановяване, но базата данни не се възстановява, огледалната база данни не може да бъде достъпена директно. Въпреки това, при зареждания само за четене, като отчети, можете да използвате огледалната база данни косвено, като създадете снимка на базата данни на огледалната база. Снимките на базата данни предоставят на клиентите достъп само за четене до данните в базата данни при създаването на снимката. Всяка конфигурация за огледало на база данни включва "главен сървър", който съдържа основната база данни, както и огледален сървър, който съдържа огледалната база данни. Огледалният сървър непрекъснато обновява огледалната база данни с основната база данни.
    Огледалото на база данни работи синхронно в режим с висока сигурност или асинхронно в режим на висока производителност. В режим с висока производителност транзакциите не трябва да чакат огледалният сървър да запише логове на диск, преди да бъдат изпратени, което максимизира производителността. В режим с висока сигурност, ангажираните транзакции се извършват от двамата партньори, но времето за забавяне на транзакцията се удължава. Най-простата конфигурация на огледалото на база данни включва само главния сървър и огледалния сървър. В тази конфигурация, ако главният сървър бъде загубен, огледалният сървър може да се използва като резервен сървър, но това може да доведе до загуба на данни. Режимът с висока сигурност поддържа режим на готовност, режим с висока сигурност с автоматично превключване. Тази конфигурация включва инстанция на трета страна, наречена "witness server", която позволява огледалният сървър да се използва като сървър за горещо архивиране. Превключването от основната база данни към огледалната обикновено отнема няколко секунди.

    Огледалото на база данни може да се използва както за топли, така и за горещи архиви.

копирам

    Репликацията не е строго функция, предназначена за висока наличност, но може да се приложи и при висока наличност. Репликацията осигурява защита на обектно ниво база данни. Репликацията използва модел публикуване-абонамент, при който данните се публикуват от основния сървър, известен като издател, на един или повече вторични абонати или абонати. Репликацията осигурява наличност и мащабируемост в реално време между тези сървъри. Поддържа филтриране за предоставяне на подмножество данни на абонатите, като същевременно поддържа и обновяване на дялове. Абонатът е онлайн и достъпен за докладване или други функции без възстановяване на заявка. SQL Server предлага четири типа репликации: репликация на моментни снимки, транзакционна репликация, репликация между peer и репликация чрез сливане.

AlwaysOnГрупа за удобство

    AlwaysOn Availability Groups е нова функция, въведена в SQL Server 2012. Осигурена е и защита на ниво база данни. Тя също така разширява лимита, че огледалното огледало на базата данни може да бъде само 1:1, така че една първична реплика може да съответства на до 4 вторични реплики (в SQL Server 2014 това ограничение е разширено до 8), от които 2 вторични реплики могат да се синхронизират като горещи резервни копия и първични реплики в реално време, а другите две асинхронни вторични реплики могат да се използват като топли резервни копия. Освен това, вторичните реплики могат да бъдат конфигурирани само за четене и да се използват за поемане на натоварването на резервните копия.

    Поради това огледалото на база данни е маркирано като "остарял" в SQL Server 2012.

    След като разберем основните концепции за висока наличност и технологиите за висока наличност, предоставени в SQL Server, нека разгледаме дизайна на стратегия за висока наличност. Планирането на стратегия с висока наличност може да се раздели на четири етапа:

Изисквания за събиране

    Първата стъпка при избора на стратегия с висока наличност несъмнено е да се съберат бизнес изискванията за създаване на SLA. RTO и RPO са най-критичните части и на тази основа се установяват реалистични очаквания за изискванията за наличност и реалистична стратегия за висока наличност, базирана на тези очаквания.

Граници на оценката

    Ограниченията за оценка не са ограничени само до ограниченията на различни технологии с висока наличност в SQL Server, но и до тези, които не са технически. Ако имате бюджет само от десетки хиляди юани, но искате да направите решение с висока наличност, базирано на външни центрове за данни и репликация на SAN, това безспорно е глупава мечта. Друго нетехническо ограничение е нивото на оперативния персонал, а често сложните архитектури означават по-квалифициран оперативен персонал. Други нетехнически ограничения включват наличието на дисково пространство в центъра за данни, дали захранването и климатизацията могат да покрият нуждите, както и времето, необходимо за прилагане на стратегията за наличност.

    Техническите ограничения включват различни функции и ограничения с висока наличност, функции, поддържани от различни версии на SQL Server, броя на процесорите и размера на паметта. Силно се препоръчва първо да се консултирате с ограниченията на различните версии и функции на SQL Server на уебсайта на Microsoft MSDN, преди да въведете политика за висока наличност.

Избрана технология

    След събиране на изисквания и оценка на ограниченията, следващата стъпка е да се изберат технологиите или комбинациите от технологии, описани по-рано в тази статия, за да отговарят на изискванията на SLA. Ако избраната технология не отговаря на SLA, лесно е да се докладва кои ограничения не отговарят на SLA, което ви позволява да поискате липсващи ресурси или да направите компромис по SLA.

Тествай, валидирай и документирай

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

Тази статия обяснява основните концепции за висока наличност, концепцията за SLA, различните видове функции с висока наличност, поддържани в SQL Server, и стъпките, необходими за проектиране на стратегия за висока наличност. Струва си да се отбележи, че макар тази статия да говори само за висока наличност на ниво база данни, високата наличност не е само въпрос на DBA, но включва и сътрудничество между различни роли като персонал по системна експлоатация и поддръжка, мрежови администратори, разработчици и мениджъри за по-добро изпълнение на SLA.