SPanel клъстер с висока наличност е група сървъри, които споделят една директория /home през NFS, репликират базите данни чрез MariaDB Galera и поддържат сайтовете ви онлайн, дори когато един от сървърите откаже.
Вие не сглобявате клъстера сами. Вместо това, избирате нужната топология, екипът за поддръжка на NS1 осигурява машините, а зоната Cluster Management в SPanel ви показва състоянието и здравето на инфраструктурата. Изграждането е преди всичко упражнение по планиране и едва след това рутина по мониторинг.
- SPanel поддържа четири топологии: Mail Redundancy (MX), DNS-Only Nodes (DNS), Dedicated Database Nodes (DB) и Full Cluster (All Services).
- Споделена /home директория през NFS плюс MariaDB Galera държи акаунтите, домейните и данните еднакви на всеки сървър.
- Зоната Cluster Management служи само за мониторинг; добавянето на възли и промяната на топологията се извършват от експертите по поддръжка на NS1.
- Същинската работа е да изберете топологията и да оразмерите VPS-ите.
Защо клъстер с висока наличност може да има смисъл
Когато хоствате на един сървър, той е единственото нео, което поддържа сайта ви жив. Ако трябва да се рестартира заради ъпдейт на ядрото или дискът започне да връща грешки, всички сайтове спират. Ако имате личен блог това е досада. Ако управлявате натоварен онлайн магазин това означава заявки за връщане на пари, обаждания от недоволни клиенти и загубени приходи.
Високата наличност премахва тази единствена точка на отказ, като разпределя натоварването върху няколко машини. Ако един сървър отпадне, останалите продължават да отговарят на заявките и посетителите не забелязват нищо. SPanel гради това върху ясни, добре познати компоненти – NFS за споделено хранилище, MariaDB Galera за репликация на базите, MaxScale за маршрутизиране на заявките – така че да можете да разберете как се държи системата, когато нещо се счупи.
Накратко
Помислете за клъстера като за натоварена кухня. Един общ килер държи всички продукти, няколко готвачи работят едновременно и ако някой се разболее, услугата продължава. Килерът е споделената директория /home през NFS, готвачите са сървърите разположени зад балансьор на натоварването, а готварската книга, която всички четат и пишат, е базата MariaDB Galera. Акаунтите, домейните и системните потребители остават синхронизирани, така че нов сайт, създаден на един възел, автоматично става достъпен навсякъде.
Кога да изберете клъстер
Изберете клъстер, когато постоянната достъпност на сайта е критична и един сървър вече не поема натоварването или риска. Това е правилният ход, когато няколко минути офлайн означават загубени продажби или нарушени договори, когато обемът на базата или пощата е надраснал една машина или когато трябва да преживеете пълен отказ на сървър, без посетителите да го усетят.
Един добре менажиран сървър е по-добрият избор, когато трафикът се поема спокойно от една машина, а редките прекъсвания не са чак толкова голям проблем. Ако се колебаете, първо вижте текущия пиков товар: повечето сайтове нямат никакъв проблем да работят на правилния сървър с добре настроени резервни копия.
Какво повечето хора разбират грешно
Честото предположение е, че „да изградиш клъстер“ означава да отвориш панел, да натиснеш Add node няколко пъти и да гледаш как се появяват сървъри. Не така стоят нещата.
Страницата Cluster Management в административния интерфейс на SPanel го казва направо: „Клъстерите се конфигурират и управляват от екипа за поддръжка. От тази страница следите живото състояние и здравето на клъстера. За промени, добавяне на сървъри или смяна на топологията се свържете с поддръжката.“ Така че екранът в административния интерфейс на SPanel е само повърхност за мониторинг. Инженерите на NS1 осигуряват хардуера, включват машините и прекрояват топологията.
Това е нарочен дизайн на управлявана услуга. Клъстерирането засяга репликация на хранилище, кворум и отказ, където една грешка може да развали данните на целия сайт. Затова тези промени минават през опитни хора, които ги правят всеки ден.
Как всъщност работи
SPanel клъстерът се състои от няколко сървъра, организирани около споделено хранилище, което експортира директорията /home към всеки член през NFS. NFS, или Network File System, е протокол, който позволява на няколко сървъра да четат и пишат едни и същи файлове по мрежата. Така файловете ви живеят на едно авторитетно място, вместо да се копират насам-натам постоянно.
Сървърите обслужват трафика зад HTTP балансьор, мейл сървърът обработва имейлите и MX записите ви, а сървърът за бази приема трафик през MaxScale – прокси за бази, което насочва всяка заявка към правилното място. Всяка машина пуска пълния комплект от услуги, а MariaDB работи с Galera – слой за синхронна репликация, който държи идентично копие на данните на всеки сървър, така че запис на една машина достига останалите веднага.
Понеже дискът и данните са споделени, един от сървърите може да напусне групата, без да наруши функцията на сайтовете – останалите машини вече имат същите файлове и същото състояние на базата. Уеб сървърите могат и локално да кешират избрани части от споделеното хранилище, за да не минават едни и същии заявки през мрежата всеки път.
Екранът Status & Health в Cluster Management на SPanel, с четирите поддържани топологии на клъстера и раздела Nodes.
До всичко това стигате от менюто Cluster Management в административния интерфейс на SPanel, което има два записа: Status & Health и DNS Cluster.
Екранът Status & Health описва четирите поддържани топологии и ви дава три раздела – Nodes, Services и Activity Log.
С какво се различава SPanel
SPanel събира информацията за клъстера в един лесен за навигиране интерфейс. Таблицата Nodes показва всеки сървър с Hostname, IP Address, Role, Load, Disk, Memory, състояние на Replication, Last Updated и Status. Разделът Services следи важните части на възел (Web Server, PHP-FPM, MariaDB, MaxScale, Exim, Dovecot, BIND, NFS и Firewall), за да откривате по-лесно евентуални проблеми. В менюто Activity Log пък ще намерите записи какво се е променило и кога.
Практически примери
Разрастващ се магазин. Full Cluster (All Services) разпределя уеб, база, поща и DNS върху няколко сървъра, така че рестарт на една машина вече не затваря магазина.
Агенция с клиентски пощенски кутии. Студио, което хоства петдесет клиентски сайта, държи имейлите да са редовни. Mail Redundancy (MX) добавя отделни сървъри Exim и Dovecot като MX записи с персонален приоритет, а пощата стои на споделен NFS, така че всеки сървър вижда една и съща входяща кутия.
Приложение, натоварващо базата. Апликации, които разчитат много на базата данни, може да използват Dedicated Database Nodes (DB). MariaDB се премества на отделни Galera сървъри, а всеки уеб сървър пуска MaxScale локално, за да насочва заявките към тях – така уеб слоят и слоят с данни се мащабират поотделно.
Избор на топология
Изберете най-малката топология, която премахва истинската ви точка на отказ.
| Топология | Какво добавя | От какво предпазва |
| Mail Redundancy (MX) | Отделни сървъри Exim и Dovecot като MX записи с персонален приоритет, поща на споделен NFS | Загубени съобщения |
| DNS-Only Nodes (DNS) | Леки сървъри с BIND за репликация на DNS зони | Отказ на единствен DNS сървър |
| Dedicated Database Nodes (DB) | MariaDB изнесена на отделни Galera машини с маршрутизиране през MaxScale | Натоварване на базата или отказ на БД |
| Full Cluster (All Services) | Уеб, база, поща и DNS на всеки сървър със споделен NFS | Прекъсвания поради хардуерни проблеми |
Накратко, правилната топология е най-малката, която премахва причината за прекъсвания – било то поща, DNS, натоварване на базата или цял сървър, който спира.
Възлите само за DNS се управляват през страницата DNS Cluster, която изрежда всеки DNS сървър с ролята и състоянието му.
Страницата DNS Cluster в SPanel със сървърите в DNS клъстера, ролята и състоянието им.
Ограничения и компромиси
SPanel не ви дава възможност сами да конструирате клъстера. Можете сами да добавяте сървъри само за DNS от страницата DNS Cluster, но уеб, база и майл сървъри се осигуряват от поддръжката на NS1. Топологията на клъстера може да се променя само от екипа за поддръжка на NS1, затова прекрояването винаги минава през тях, никога през административния интерфейс.
Клъстерът не е и резервно копие: репликацията копира грешките ви също толкова вярно, колкото и добрите данни, така че при грешно изтриване или инфекция от ransomware, пак имате нужда от възстановими архиви. Клъстерирането е и значително по-скъпо, което значи, че е подходящо само когато бюджетът е сериозен и прекъсванията трябва да се избегнат на всяка цена.
Изграждане на клъстера
Изграждането на SPanel клъстер е поредица от решения, които трябва да вземете.
- Изберете топологията. Съпоставете реалния риск от прекъсване с една от четирите опции по-горе: поща, DNS, база или всичко наведнъж.
- Оразмерете сървърите. Оценете трафика, натоварването на базата и обема на имейл акаунтите, после решете колко сървъра и колко CPU, памет и диск трябват за всеки.
- Поискайте клъстера. Свържете се с поддръжката на NS1 с избраната топология и спецификации и нашият екип ще конфигурира всичко.
- Проверете в Status & Health. След като клъстерът е онлайн, потвърдете, че всеки сървър е здрав, репликацията е актуална и всяка услуга свети в зелено.
- Следете и преглеждайте. Наблюдавайте обобщаващите плочки и Activity Log с времето и преразглеждайте спецификациите на сървърите, когато видите повишаване на трафика.
Когато надраснете текущата форма, повтаряте цикъла: решавате промяната, после молите поддръжката да я направи.
ЧЗВ
В: Мога ли сам да добавя сървър към клъстера в SPanel?
О: Възможно е да добавяте само DNS сървъри. Страницата DNS Cluster ви позволява сами да добавите вторичен DNS сървър от административния интерфейс. Уеб, база и мейл сървъри се добавят от поддръжката на NS1. Същото важи и за промени по топологията на клъстера. Вие избирате топологията и спецификациите, инженерите на NS1 осигуряват сървърите, а вие проверявате резултата в Status & Health.
В: Какви топологии поддържа SPanel?
О: Има четири опции. Mail Redundancy (MX) добавя отделни сървъри Exim и Dovecot като MX записи. DNS-Only Nodes (DNS) пускат BIND за репликация на зони. Dedicated Database Nodes (DB) преместват MariaDB върху Galera сървъри с маршрутизиране през MaxScale. Full Cluster (All Services) пуска уеб, база, мейли DNS услуги на всеки сървър със споделено NFS хранилище.
В: Как хранилището остава еднакво между възлите?
О: Синхронизирания диск експортира директорията /home към всеки сървър в клъстера чрез NFS, така че всички файлове на сайтовете живеят на едно авторитетно място, вместо да се копират между машините. Базите остават еднакви чрез репликация MariaDB Galera, а MaxScale насочва заявките към правилния бекенд. Понеже файловете и данните са споделени, един сървър може да откаже, без да афектира достъпността на сайтовете.
В: Клъстерът заместител ли е на резервните копия?
О: Не, и да го третирате като такъв е рисковано. Репликацията копира всяка промяна, включително случайни изтривания, на всеки сървър веднага. Клъстерът пази от хардуерни проблеми и прекъсвания, не от човешка грешка или атака. Дръжте отделни, възстановими резервни копия, за да се върнете към добра точка, когато репликацията вярно разнесе грешката.
В: Как да разбера, че клъстерът е здрав?
О: Отворете Cluster Management, после Status & Health. Разделът Nodes показва натоварване, диск, памет и състояние на репликацията за всеки възел, плюс колоната Status. Разделът Services отчита Web Server, PHP-FPM, MariaDB, MaxScale, Exim, Dovecot, BIND, NFS и Firewall за всеки възел. Обобщаващите табове показват от пръв поглед кои сървъри са онлайн и кои са остарели.
В: Кога един сървър е по-добрият избор?
О: Клъстерът е значително по-скъп от стандартните хостинг решения, затова си заслужава само когато няколко минути прекъсване може да имат сериозни последици за бизнеса. За повечето уебсайтове един добре управляван сървър със солидни резервни копия върши работа.
