| Осигуряване на висока надеждност в Oracle Database 10g |
| Четвъртък, 06 Ноември 2008 10:47 |
|
Под „висока надеждност“ на база данни обикновено разбираме изграждането и внедряването на такава архитектура, при която се стремим базата данни да е максимално достъпна, дори при възникване на сериозни софтуерни или хардуерни проблеми в нейната конфигурация. Преди да започнем да говорим за различните архитектури препоръчвани от Oracle с цел осигуряването на висока надеждност обаче, трябва да направим едно важно уточнение. Въпреки че обикновено използваме термина „база данни“, за да обозначим цялата система за управление на база данни, това не е напълно точно. Ако погледнем внимателно техническата документация, ще видим че Oracle разделят Oracle Database на две логически структури. Първата се нарича „инстанция“, а втората „база данни“. Инстанцията е набор от процеси и структури в паметта. Базата данни са физическите файлове, в които процесите записват или четат информация. Комбинацията от база данни и инстанция наричаме обобщено „Oracle сървър“.  По-голямата част от паметта, която се заделя в инстанцията се нарича System Global Area. В нея различните процеси пазят информацията за прочетените или подготвените за запис блокове с данни, за операциите които предстоят или които вече са извършени. Самите процеси в инстанцията извършват същинските задачи по пренос на данните от и към паметта, по обслужване на потребителските заявки, по автоматичното архивиране, по самодиагностиката и така нататък. При използването на една единствена машина за Oracle сървър, тя се превръща в слабо място за системата. Ако се появи хардуерен проблем или проблем на нивото на операционната система, това може да наруши работоспособността на Oracle Database. За предотвратяване на такива ситуации Oracle предлага решение, наречено Real Application Cluster (или RAC). Идеята на RAC е да имаме няколко едновременно работещи инстанции (всяка на отделна физическа машина), които са свързани към обща база данни. Това се реализира чрез няколко сървъра, свързани към споделен сторидж. Схематично нещата изглеждат по следния начин:  Когато използваме един единствен Oracle сървър, върху него разполагаме една инстанция и една база данни. Отношението между тях е едно към едно. При RAC архитектура, две или повече инстанции обслужват потребителите едновременно. Използването на RAC ни дава два големи плюса. Първо, ако отпадне едната инстанция другата ще поеме всички заявки и работата на потребителите няма да бъде прекъсната. Второ, Oracle автоматично балансира натоварването между двете инстанции, като по този начин обединява тяхната изчислителна мощност. Ако се замислим малко по-сериозно ще видим, че използването на подобна архитектура повдига два съществени въпроса. Първо, не бихме искали потребителите да знаят за съществуването на двете инстанции и да решават към коя да се свържат. За да бъде архитектурата изчистена в това отношение, ще ни е нужна „входна точка“, която автоматично да насочва клиентите към едната или другата инстанция, като същевременно балансира натоварването. За тази цел използваме Oracle Net Services – решение, което осигурява свързаност за хетерогенни системи и е включено в Oracle Database. Второто нещо, за което трябва да се погрижим е комуникацията между двете инстанции. Тъй като те споделят общи данни (разположени на сториджа), те трябва да обменят информация за това коя инстанция какви данни променя, каква информация има кеширана при себе си, в какво състояние са нейните процеси и изобщо – данни, с които инстанциите синхронизират работата си. За осигуряването на тази функционалност в RAC се грижи Oracle Clusterware. Това е специализиран софтуер, който осигурява комуникацията между отделните елементи на клъстера (в нашия случай – инстанциите), а също така представя няколко инстанции като един логически сървър. Всъщност, една от уникалните възможности на Oracle RAC е използването на комуникацията между отделните инстанции в клъстера за споделяне на кеширана информация. По този начин всички инстанции имат равноправен достъп за запис на данни и не е нужно да се изчакват или да разделят данните помежду си. С тези две добавки, новата схема на клъстерното решение изглежда по следния начин:  Както виждаме на схемата, върху сториджа трябва да отделим допълнително място, което се използва от Oracle Clusterware. Двете неща, които той разполага там са Oracle Clusterware Repository (OCR) и Voting Disk. OCR съдържа информация за отделните сървъри в клъстера, а Voting Disk-ът се използва от различните сървъри за определяне на състоянието при отпадане на комуникацията с останалата част от клъстера. Описаната архитектура е най-често използваната, когато искаме да осигурим работоспособността на Oracle Database до рамките на отпадане на физически сървър. Ако искаме да се защитим от едновременното отпадане на всички сървъри, включително и сториджа, тогава използваме решението Oracle Data Guard. Data Guard технологията позволява промените извършени в базата данни автоматично да се приложат върху отдалечен Oracle сървър. По този начин можем да изградим втора инсталация с два или повече нови сървъра и допълнителен сторидж, а Data Guard да се грижи промените направени в главната ни инсталация (primary database) да се отразят и в резервната (standby database).  В този случай, при отпадане на първичната ни инсталация, потребителите могат незабавно да се превключат към резервната и да продължат работа без никакво забавяне или загуба на данни. Data Guard най-често се използва в сценарии за защита от бедствия (така нареченото Disaster Recovery). Повечето такива стратегии препоръчват двете инсталации, които Data Guard обслужва да бъдат отдалечени една от друга минимум на 150 километра, с цел предпазване от стихийни бедствия. Използването на RAC и Data Guard ни дава не само възможност да постигнем висока надеждност. Чрез тях можем да направим баланс на натоварването между различните инстанции. Честа практика е операциите по отчетност и анализ (тоест тези които само извличат, а не променят данните) да бъдат насочени към резервната база. Друг огромен плюс е възможността да прилагаме пачове върху клъстера, като действаме сървър по сървър. Идеята е, че можем да изключим един от сървърите, а останалите ще поемат клиентите, които той обслужва. Когато приключим и го активираме отново, клъстерът автоматично ще разпредели част от клиентите на останалите към него. По този начин никога не се налага да изключваме целия клъстер, а когато приключим с последния сървър целият клъстер ще бъде с приложени пачове. |
Коментари