Тази бележка завършва цикъла за архивиране. Ще се обсъди логическата организация на специален сървър (или VPS), удобен за архивиране, а също така ще се предложи опция за бързо възстановяване на сървър от резервно копие без много прекъсвания в случай на авария.
Сурови данни
Специализираният сървър най-често има поне два твърди диска, които служат за организиране на RAID масив от първо ниво (mirror). Това е необходимо, за да може да продължи работата на сървъра, ако един диск откаже. Ако това е обикновен специализиран сървър, може да има отделен хардуерен RAID контролер с технология за активно кеширане на SSD, така че в допълнение към обикновените твърди дискове да могат да бъдат свързани един или повече SSD. Понякога се предлагат специални сървъри, в които единствените локални дискове са SATADOM (малки дискове, структурно флашка, свързана към SATA порт), или дори обикновена малка (8-16GB) флашка, свързана към специален вътрешен порт, и данните се вземат от системата за съхранение, свързана чрез специална мрежа за съхранение (Ethernet 10G, FC и т.н.) и има специални сървъри, които се зареждат директно от системата за съхранение. Няма да разглеждам такива опции, тъй като в такива случаи задачата за архивиране на сървъра плавно преминава към специалиста, който поддържа системата за съхранение; обикновено има различни патентовани технологии за създаване на моментни снимки, вградена дедупликация и други радости на системния администратор , разгледани в предишните части на тази серия. Обемът на дисковия масив на специален сървър може да достигне няколко десетки терабайта, в зависимост от броя и размера на дисковете, свързани към сървъра. В случая на VPS обемите са по-скромни: обикновено не повече от 100 GB (но има и повече), а тарифите за такъв VPS лесно могат да бъдат по-скъпи от най-евтините специализирани сървъри от същия хост. VPS най-често има един диск, защото под него ще има система за съхранение (или нещо хиперконвергирано). Понякога VPS има няколко диска с различни характеристики, за различни цели:
- малка система - за инсталиране на операционната система;
- големи - съхраняване на потребителски данни.
Когато преинсталирате системата с помощта на контролния панел, дискът с потребителски данни не се презаписва, но системният диск се запълва напълно. Освен това, в случай на VPS, хостът може да предложи бутон, който прави моментна снимка на състоянието на VPS (или диска), но ако инсталирате собствена операционна система или забравите да активирате желаната услуга във VPS, някои от данните може все още да бъдат загубени. В допълнение към бутона обикновено се предлага услуга за съхранение на данни, най-често много ограничена. Обикновено това е акаунт с достъп през FTP или SFTP, понякога заедно със SSH, с намалена обвивка (например rbash) или ограничение за изпълнение на команди чрез authorized_keys (чрез ForcedCommand).
Специализираният сървър е свързан към мрежата чрез два порта със скорост 1 Gbps, понякога това могат да бъдат карти със скорост 10 Gbps. VPS най-често има един мрежов интерфейс. Най-често центровете за данни не ограничават скоростта на мрежата в центъра за данни, но ограничават скоростта на достъп до Интернет.
Типичното натоварване на такъв специален сървър или VPS е уеб сървър, база данни и сървър на приложения. Понякога могат да бъдат инсталирани различни допълнителни спомагателни услуги, включително за уеб сървър или база данни: търсачка, пощенска система и др.
Специално подготвен сървър действа като място за съхранение на резервни копия, за което ще пишем по-подробно по-късно.
Логическа организация на дисковата система
Ако имате RAID контролер или VPS с един диск и няма специални предпочитания за работата на дисковата подсистема (например отделен бърз диск за база данни), цялото свободно пространство се разделя, както следва: един дял се създава и върху него се създава LVM група томове, в нея се създават няколко тома: 2 малки с еднакъв размер, използвани като основна файлова система (променени един по един по време на актуализации за възможност за бързо връщане назад, идеята е взета от дистрибуцията на Calculate Linux), друг е за суап дяла, останалото свободно пространство е разделено на малки томове, използвани като основна файлова система за пълноценни контейнери, дискове за виртуални машини, файл системи за акаунти в /home (всеки акаунт има собствена файлова система), файлови системи за контейнери на приложения.
Важна забележка: томовете трябва да са напълно самостоятелни, т.е. не трябва да зависят един от друг или от основната файлова система. В случай на виртуални машини или контейнери, тази точка се наблюдава автоматично. Ако това са контейнери на приложения или домашни директории, трябва да помислите за разделяне на конфигурационните файлове на уеб сървъра и другите услуги по такъв начин, че да елиминирате зависимостите между томовете, доколкото е възможно. Например всеки сайт работи от собствен потребител, конфигурационните файлове на сайта са в домашната директория на потребителя, в настройките на уеб сървъра, конфигурационните файлове на сайта не са включени чрез /etc/nginx/conf.d/.conf и например /home//configs/nginx/*.conf
Ако има няколко диска, можете да създадете софтуерен RAID масив (и да конфигурирате неговото кеширане на SSD, ако има нужда и възможност), върху който можете да изградите LVM според предложените по-горе правила. Също така в този случай можете да използвате ZFS или BtrFS, но трябва да помислите два пъти за това: и двете изискват много по-сериозен подход към ресурсите и освен това ZFS не е включена в ядрото на Linux.
Независимо от използваната схема, винаги си струва предварително да оцените приблизителната скорост на запис на промените на дисковете и след това да изчислите количеството свободно пространство, което ще бъде запазено за създаване на моментни снимки. Например, ако нашият сървър записва данни със скорост 10 мегабайта в секунда, а размерът на целия масив от данни е 10 терабайта - времето за синхронизация може да достигне един ден (22 часа - толкова ще бъде прехвърлен такъв обем през мрежата 1 Gbps) - струва си да резервирате около 800 GB. В действителност цифрата ще бъде по-малка, можете спокойно да я разделите на броя на логическите томове.
Сървърно устройство за резервно съхранение
Основната разлика между сървъра за съхранение на резервни копия е големите, евтини и сравнително бавни дискове. Тъй като съвременните твърди дискове вече са преминали границата от 10TB на един диск, е необходимо да се използват файлови системи или RAID с контролни суми, тъй като по време на повторното изграждане на масива или възстановяването на файловата система (няколко дни!) вторият диск може да се повреди поради до повишено натоварване. На дискове с капацитет до 1TB това не беше толкова чувствително. За простота на описанието предполагам, че дисковото пространство е разделено на две части с приблизително еднакъв размер (отново, например, използвайки LVM):
- обеми, съответстващи на сървърите, използвани за съхраняване на потребителски данни (последният направен архив ще бъде разположен на тях за проверка);
- томове, използвани като хранилища на BorgBackup (данните за архивиране ще отиват директно тук).
Принципът на работа е, че за всеки сървър се създават отделни томове за хранилищата на BorgBackup, където ще отидат данни от бойните сървъри. Репозиториите работят в режим само за добавяне, което елиминира възможността за умишлено изтриване на данни и поради дедупликация и периодично почистване на хранилища от стари архиви (остават годишни копия, месечно за последната година, седмично за последния месец, ежедневно за миналата седмица, евентуално в специални случаи - на час за последния ден: общо 24 + 7 + 4 + 12 + годишно - приблизително 50 копия за всеки сървър).
Репозиториите на BorgBackup не активират режим само за добавяне; вместо това се използва ForcedCommand в .ssh/authorized_keys нещо подобно:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Посоченият път съдържа скрипт за обвивка върху borg, който в допълнение към стартирането на двоичния файл с параметри, допълнително стартира процеса на възстановяване на резервното копие след премахване на данните. За да направите това, скриптът за обвивка създава файл с етикети до съответното хранилище. Последният направен архив се възстановява автоматично в съответния логически том след приключване на процеса на попълване на данни.
Този дизайн ви позволява периодично да почиствате ненужните резервни копия и също така не позволява на бойните сървъри да изтрият каквото и да било от сървъра за съхранение на резервни копия.
Процес на архивиране
Инициаторът на архивирането е самият специален сървър или VPS, тъй като тази схема дава повече контрол върху процеса на архивиране от страна на този сървър. Първо се прави моментна снимка на състоянието на активната основна файлова система, която се монтира и качва с помощта на BorgBackup на резервния сървър за съхранение. След като прихващането на данните приключи, моментната снимка се демонтира и изтрива.
Ако има малка база данни (до 1 GB за всеки сайт), се прави дъмп на базата данни, който се записва в съответния логически том, където се намират останалите данни за същия сайт, но така, че дъмпът да е не е достъпен през уеб сървъра. Ако базите данни са големи, трябва да конфигурирате „горещо“ премахване на данни, например, като използвате xtrabackup за MySQL или да работите с WAL с archive_command в PostgreSQL. В този случай базата данни ще бъде възстановена отделно от данните на сайта.
Ако се използват контейнери или виртуални машини, трябва да конфигурирате qemu-guest-agent, CRIU или други необходими технологии. В други случаи най-често не са необходими допълнителни настройки - ние просто създаваме моментни снимки на логически томове, които след това се обработват по същия начин като моментна снимка на състоянието на основната файлова система. След като данните бъдат заснети, снимките се изтриват.
По-нататъшна работа се извършва на сървъра за резервно съхранение:
- последното архивиране, направено във всяко хранилище, се проверява,
- проверява се наличието на файл за маркиране, което показва, че процесът на събиране на данни е завършен,
- данните се разширяват до съответния локален обем,
- файлът с етикет се изтрива
Процес на възстановяване на сървъра
Ако основният сървър умре, тогава се стартира подобен специален сървър, който се зарежда от някакъв стандартен образ. Най-вероятно изтеглянето ще се извърши по мрежата, но техникът от центъра за данни, който настройва сървъра, може веднага да копира това стандартно изображение на един от дисковете. Изтеглянето се извършва в RAM, след което започва процесът на възстановяване:
- направена е заявка за прикачване на блоково устройство чрез iscsinbd или друг подобен протокол към логически том, съдържащ основната файлова система на починалия сървър; Тъй като основната файлова система трябва да е малка, тази стъпка трябва да бъде завършена за няколко минути. Буутлоудърът също е възстановен;
- структурата на локалните логически томове се пресъздава, логическите томове се прикачват от резервния сървър с помощта на модула на ядрото dm_clone: възстановяването на данни започва и промените се записват незабавно на локалните дискове
- стартира се контейнер с всички налични физически дискове - функционалността на сървъра е напълно възстановена, но с намалена производителност;
- след приключване на синхронизирането на данните, логическите томове от резервния сървър се изключват, контейнерът се изключва и сървърът се рестартира;
След рестартиране сървърът ще има всички данни, които са били там по време на създаването на архива, и ще включва също всички промени, направени по време на процеса на възстановяване.
Други статии от поредицата
Архивиране Част 7: Заключения
Каня ви да обсъдите предложения вариант в коментарите, благодаря ви за вниманието!
Източник: www.habr.com