Наличността на базата данни е един от най-важните аспекти на архитектурата на приложението. Въпреки че предотвратяването на престой в центъра за данни е даденост, в крайна сметка това ще се случи на всички. Дори и най-добре работещите центрове за данни ще се повредят напълно от време на време. Например прекъсванията на Amazon AWS от 8/26/13 и 9/13/13. Важният въпрос, който трябва да зададете, е дали това е приемливо за вашето приложение? Повечето приложения могат да понасят известно прекъсване от време на време, но някои приложения изискват близо 100% време на работа и архитектурата на базата данни на тези приложения изисква по-преднамерен подход към проектиране. Закъсненията между центровете за данни обикновено са доста големи, така че трябва да се обмисли внимателно дизайна на внедряването на хостинг на MongoDB.
Цели за работа на MongoDB
- Вашата база данни трябва да е издигната и да може да се записва, дори ако целият център за данни се повреди.
- Отказът на вашата база данни трябва да бъде автоматично в случай на повреда на сървъра/центъра за данни.
- Една грешка в сървъра не трябва да кара основния да превключи към друг център за данни.
Дизайн на център за данни
За да удовлетворим нашите цели, измислихме три дизайна на центъра за данни, използвайки набор от реплики 4+1:
- Център за данни 1: Първичен (Приоритет 10), Среден 0 (Първен 9)
- Център за данни 2: Вторично 1 (Приоритет 8), Вторично 2 (Приоритет 7)
- Център за данни 3: Арбитър
Поставяме двама пълноправни членове във всеки от първите два центъра за данни и арбитър в третия център за данни. Също така конфигурирахме приоритета за всеки сървър, така че да можем да контролираме кой член става основен в случай на повреда на сървъра.
Има няколко недостатъка на тази гео- разпределена архитектура:
- Ако имате приложение с тежък запис, вторичните елементи в различен център за данни винаги ще изостават поради по-голямата латентност. Ако някои данни са от решаващо значение, може да искате да използвате загриженост за запис на MongoDB за „Мнозинство“, за да сте сигурни, че всички възли предават данните.
- Комплектациите на общността на MongoDB нямат активиран SSL. Може да искате да направите компилация с активиран SSL или да използвате MongoDB DBaaS в ScaleGrid, така че данните, преминаващи през региони, да бъдат криптирани.
Наличност на Amazon AWS / EC2
Ако внедрявате MongoDB на AWS, всеки център за данни на тази снимка съответства на регион на Amazon, а не на зона за наличност. Amazon не предоставя гаранции за наличност в една зона за наличност, SLA са за целия регион. Ако разгръщате в зони за наличност, вашият SLA е 99,95%, което все още е страхотен SLA – обаче, ако цял регион намалее, вашата база данни ще намалее. Освен това, някои региони на AWS имат само две зони за наличност, така че трябва да се обърне специално внимание на поставянето на третия възел в различен регион, така че престой в един единствен регион да не сваля цялата база данни.
Наличност с по-ниски разходи в различните географски райони
По-опростена версия на същата архитектура използва само три сървъра и поставя само една реплика във всеки център за данни. Недостатъкът на този подход е, че един отказ на сървъра ще накара основния да се движи между центровете за данни. Тази архитектура обаче струва по-малко от първата архитектура. В зависимост от вашия сценарий може да работи за вас.
Има много начини за постигане на висока работоспособност с MongoDB и това е точно начинът, който работи за нашите нужди. Ако имате други интересни архитектури, моля, изпратете ни имейл на [email protected]. Ще се радваме да чуем вашите мисли!
