Тази бележка завършва цикъла за резервно копиране. В нея ще става въпрос за логичната организация на физическия сървър (или VPS), удобна за резервно копиране, а също така ще бъде предложен вариант за бързо възстановяване на сървъра от резервно копие без значителни прекъсвания в случай на авария.
Изходни данни
Физическият сървър обикновено има минимум два твърди диска, които служат за организация на RAID масив от първо ниво (огледало). Това е необходимо, за да може сървърът да продължи работата си, ако един от дисковете се повреди. Ако това е обикновен физически сървър, може да има отделен хардуерният RAID контролер с активна технология за кеширане на SSD, така че в допълнение към обикновените твърди дискове може да бъде свързан един или повече SSD. Понякога се предлагат физически сървъри, в които от локалните дискове присъстват само SATADOM (малки дискове, конструктивно — флаш памет, свързваща се в SATA порт), или дори обикновена малка (8-16GB) флаш памет, свързваща се в специален вътрешен порт, а данните се вземат от СХД, свързана по отделна мрежа за съхранение на данни (Ethernet 10G, FC и т.н.), а има и физически сървъри, които зареждат директно от СХД. Подобни варианти няма да разглеждам, тъй като в такива случаи задачата по резервно копиране на сървъра плавно преминава на специалиста, който обслужва СХД, а обикновено там има различни фирмени технологии за създаване на снимки на състоянието, вградена дедупликация и други удобства за системния администратор, разгледани в предишните части от този цикъл. Обемът на дисковия масив на физическия сървър може да достигне няколко десетки терабайта, в зависимост от броя и обема на дисковете, свързани към сървера. В случай на VPS, обемите са по-скромни: обикновено не повече от 100GB (но може да има и по-големи), а тарифите за такива VPS лесно могат да бъдат по-скъпи от най-евтините физически сървъри на същия хостър. Често VPS има един диск, тъй като под него ще бъде СХД (или нещо хиперконвергентно). Понякога VPS има няколко диска с различни характеристики за различни цели:
- малък системен — за инсталиране на операционна система;
- голям — за съхранение на потребителски данни.
При повторно инсталиране на системата чрез контролния панел, диск с потребителски данни не се изтрива, а системният диск се презаписва напълно. Също така, в случай на VPS, хостващата компания може да предлага бутон за създаване на моментна снимка на състоянието на VPS (или диска), но ако се инсталира собствена операционна система или се забрави да се активира необходимата услуга в VPS, част от данните все пак може да бъде загубена. В допълнение към бутона обикновено се предлага услуга за съхранение на данни, която в повечето случаи е силно ограничена. Обикновено става въпрос за акаунт с достъп по протоколите FTP или SFTP, понякога в combinatie с SSH, с ограничен shell (например rbash), или ограничение за стартиране на команди чрез authorized_keys (чрез ForcedCommand).
Дедикейтед серверът е свързан с мрежата чрез два порта с скорост 1 Гбит/сек, понякога това могат да бъдат карти със скорост 10 Гбит/сек. При 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. В реалността цифрата ще бъде по-малка, може смело да я разделим на броя логически томове.
Устройство на сървъра за съхранение на резервни копия
Основната разлика на сървъра за съхранение на резервни копия е, че той използва големи, евтини и относително бавни дискове. Тъй като съвременните HDD вече надминаха бариерата от 10 TB в един диск — задължително е да се използват файлови системи или RAID с контролни суми, защото във времето на преподреждане на масива или възстановяване на файловата система (няколко дни!) вторият диск може да се повреди поради повишеното натоварване. При дискове с капацитет до 1 TB, това не беше толкова чувствително. За простота на описанието предполагам, че дисковото пространство е разделено на две приблизително равни по размер части (отново, например, с помощта на 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 c archive_command в PostgreSQL. В този случай базата данни ще бъде възстановена отделно от данните на сайтовете.
Ако се използват контейнери или виртуални машини, следва да се настрои qemu-guest-agent, CRIU или други необходими технологии. В другите случаи допълнителни настройки най-често не са необходими — просто създаваме снимки на логическите томове, които след това се обработват подобно на снимката на състоянието на кореновата файлова система. След изтегляне на данни, снимките биват изтривани.
По-нататъшната работа продължава на сървъра за съхранение на резервни копия:
- Проверява се последната направена резервна копия във всеки репозиторий,
- Проверява се наличието на файл с етикет, указващ, че процесът на извличане на данни е завършен,
- Извършва се разгръщане на данните на съответния локален том,
- Изтрива се файлът с етикет
Процесът на възстановяване на работоспособността на сървъра
Ако основният сървър се срине, се стартира аналогичен выделен сървър, който се зарежда от стандартен образ. По-вероятно е зареждането да се осъществи по мрежата, но техникът в ЦОД, който настройва сървера, може веднага да копира този стандартен образ на един от дисковете. Зареждането се извършва в оперативната памет, след което започва процесът на възстановяване:
- Извършва се заявка за присъединяване на блочно устройство по iscsinbd или друг подобен протокол за логически том, съдържащ кореновата файлова система на сринатия сървър; тъй като кореновата файлова система трябва да бъде малка — този етап трябва да бъде завършен за няколко минути. Осъществява се също така възстановяване на зареждача;
- Възстановява се структурата на локалните логически томове, присъединяват се логическите томове от сървъра за резервно копие с помощта на модула на ядрото dm_clone: започва процесът на възстановяване на данните и промените се записват веднага на локалните дискове
- Стартира се контейнер с всичките налични физически дискове — възстановява се напълно работоспособността на сървъра, но с понижена производителност;
- След приключване на синхронизацията на данните, логическите томове от сървъра за резервно копие се отсъединяват, контейнерът се изключва, сървърът се презарежда;
След презареждането сървърът ще има всички данни, които са били в момента на създаването на резервното копие, и ще включва всички изменения, които са направени по време на възстановяването.
Други статии от цикъла
Резервно копиране, част 7: Изводи
Приканвам да обсъдим предложената опция в коментарите, благодаря за вниманието!
Източник: habr.com
