Ĉi tiu noto kompletigas la ciklon pri sekurkopio. Ĝi diskutos la logikan organizon de dediĉita servilo (aŭ VPS), oportuna por sekurkopio, kaj ankaŭ ofertos eblon por rapide restarigi servilon de sekurkopio sen multe da malfunkcio en kazo de katastrofo.
Fontaj datumoj
Diligenta servilo plej ofte havas almenaŭ du malmolajn diskojn, kiuj servas por organizi unuanivelan RAID-tabelon (spegulo). Ĉi tio estas necesa por povi daŭrigi funkcii la servilon se unu disko malsukcesas. Se ĉi tio estas regula dediĉita servilo, povas ekzisti aparta aparatara RAID-regilo kun aktiva kaŝmemorteknologio sur SSD, tiel ke krom regulaj malmolaj diskoj, unu aŭ pluraj SSD-oj povas esti konektitaj. Kelkfoje estas ofertitaj diligentaj serviloj, en kiuj la nuraj lokaj diskoj estas SATADOM (malgrandaj diskoj, strukture poŝmemoro konektita al SATA-haveno), aŭ eĉ ordinara malgranda (8-16GB) poŝmemoro konektita al speciala interna haveno, kaj la datumoj estas prenitaj de la stokadsistemo , konektita per dediĉita stokadoreto (Ethernet 10G, FC, ktp.), kaj ekzistas dediĉitaj serviloj kiuj estas ŝarĝitaj rekte de la stokadosistemo. Mi ne konsideros tiajn eblojn, ĉar en tiaj kazoj la tasko de sekurkopio de la servilo glate pasas al la specialisto, kiu prizorgas la stokadsistemon; kutime ekzistas diversaj proprietaj teknologioj por krei momentfotojn, enkonstruitan deduplikadon kaj aliajn ĝojojn de la sistemadministranto. , diskutita en la antaŭaj partoj de ĉi tiu serio. La volumeno de diskatablo de diligenta servilo povas atingi plurajn dekojn da terabajtoj, depende de la nombro kaj grandeco de diskoj konektitaj al la servilo. En la kazo de VPS, la volumoj estas pli modestaj: kutime ne pli ol 100GB (sed estas ankaŭ pli), kaj la tarifoj por tia VPS facile povas esti pli multekostaj ol la plej malmultekostaj dediĉitaj serviloj de la sama gastiganto. VPS plej ofte havas unu diskon, ĉar estos konserva sistemo (aŭ io hiperkonverĝa) sub ĝi. Kelkfoje VPS havas plurajn diskojn kun malsamaj karakterizaĵoj, por malsamaj celoj:
- small system - por instali la operaciumon;
- granda - stokado de datumoj de uzantoj.
Kiam vi reinstalas la sistemon per la kontrolpanelo, la disko kun uzantdatenoj ne estas anstataŭita, sed la sistema disko estas tute replenigita. Ankaŭ, en la kazo de VPS, la gastiganto povas proponi butonon kiu prenas momentfoton de la stato de la VPS (aŭ disko), sed se vi instalas vian propran operaciumon aŭ forgesas aktivigi la deziratan servon ene de la VPS, iuj de la datumoj ankoraŭ povas esti perditaj. Krom la butono, oni kutime proponas servon de konservado de datumoj, plej ofte tre limigita. Ĉi tio estas kutime konto kun aliro per FTP aŭ SFTP, foje kune kun SSH, kun senŝeligita ŝelo (ekzemple, rbash), aŭ limigo pri rulado de komandoj per authorized_keys (per ForcedCommand).
Diligenta servilo estas konektita al la reto per du havenoj kun rapido de 1 Gbps, foje ĉi tiuj povas esti kartoj kun rapido de 10 Gbps. VPS plej ofte havas unu retan interfacon. Plej ofte, datumcentroj ne limigas la retan rapidon ene de la datumcentro, sed ili limigas la rapidecon de interreta aliro.
La tipa ŝarĝo de tia dediĉita servilo aŭ VPS estas retservilo, datumbazo kaj aplikaĵoservilo. Foje diversaj aldonaj helpservoj povas esti instalitaj, inkluzive por retservilo aŭ datumbazo: serĉilo, poŝtsistemo ktp.
Speciale preparita servilo funkcias kiel spaco por konservi rezervajn kopiojn; ni skribos pri ĝi pli detale poste.
Logika organizo de la disksistemo
Se vi havas RAID-regilon aŭ VPS kun unu disko, kaj ne ekzistas specialaj preferoj por la funkciado de la disksubsistemo (ekzemple aparta rapida disko por datumbazo), la tuta libera spaco estas dividita jene: unu sekcio. estas kreita, kaj LVM-voluma grupo estas kreita sur ĝi, pluraj volumoj estas kreitaj en ĝi: 2 malgrandaj samgrandaj, uzataj kiel la radika dosiersistemo (ŝanĝita unu post alia dum ĝisdatigoj por la ebleco de rapida retroigo, la ideo estis prenita el la distribuo Kalkuli Linukson), alia estas por la interŝanĝa sekcio, la resto de la libera spaco estas dividita en malgrandaj volumoj , uzata kiel la radika dosiersistemo por plenrajtaj ujoj, diskoj por virtualaj maŝinoj, dosiero. sistemoj por kontoj en /home (ĉiu konto havas sian propran dosiersistemon), dosiersistemojn por aplikaj ujoj.
Grava noto: volumoj devas esti tute memstaraj, t.e. ne devus dependi unu de la alia aŭ de la radika dosiersistemo. En la kazo de virtualaj maŝinoj aŭ ujoj, ĉi tiu punkto estas observata aŭtomate. Se ĉi tiuj estas aplikaj ujoj aŭ hejmaj dosierujoj, vi devus pensi pri apartigo de la agordaj dosieroj de la retservilo kaj aliaj servoj tiel, ke kiel eble plej eliminu dependecoj inter la volumoj. Ekzemple, ĉiu retejo funkcias de sia propra uzanto, la retejo-agordaj dosieroj estas en la hejma dosierujo de la uzanto, en la retservilo-agordoj, retejo-agordaj dosieroj ne estas inkluzivitaj per /etc/nginx/conf.d/..conf, kaj, ekzemple, /home//configs/nginx/*.conf
Se estas pluraj diskoj, vi povas krei programaron RAID-tabelon (kaj agordi ĝian kaŝmemoron sur SSD, se estas bezono kaj ŝanco), sur kiu vi povas konstrui LVM laŭ la reguloj proponitaj supre. Ankaŭ en ĉi tiu kazo, vi povas uzi ZFS aŭ BtrFS, sed vi devus pensi dufoje pri tio: ambaŭ postulas multe pli seriozan aliron al rimedoj, kaj krome, ZFS ne estas inkluzivita kun la Linukso-kerno.
Sendepende de la uzata skemo, ĉiam indas taksi anticipe la proksimuman rapidecon de skribado de ŝanĝoj al diskoj, kaj poste kalkuli la kvanton da libera spaco, kiu estos rezervita por krei momentfotojn. Ekzemple, se nia servilo skribas datumojn je rapideco de 10 megabajtoj sekundo, kaj la grandeco de la tuta datumtabelo estas 10 terabajtoj - la sinkroniga tempo povas atingi tagon (22 horoj - jen kiom tia volumo estos translokigita. tra la reto 1 Gbps) - indas rezervi ĉirkaŭ 800 GB. En realeco, la figuro estos pli malgranda; vi povas sekure dividi ĝin per la nombro da logikaj volumoj.
Rezerva stoka servila aparato
La ĉefa diferenco inter servilo por stoki rezervajn kopiojn estas ĝiaj grandaj, malmultekostaj kaj relative malrapidaj diskoj. Ĉar modernaj HDD-oj jam transpasis la 10TB-stangon en unu disko, necesas uzi dosiersistemojn aŭ RAID kun kontrolsumoj, ĉar dum la rekonstruado de la tabelo aŭ la restarigo de la dosiersistemo (plurajn tagojn!) la dua disko povas malsukcesi pro tio. al pliigita ŝarĝo. Sur diskoj kun kapacito de ĝis 1TB tio ne estis tiel sentema. Por simpleco de priskribo, mi supozas, ke la diskospaco estas dividita en du partojn de proksimume egala grandeco (denove, ekzemple, uzante LVM):
- volumoj respondaj al la serviloj uzataj por stoki uzantdatenojn (la lasta sekurkopio farita estos deplojita sur ili por konfirmo);
- volumoj uzataj kiel deponejoj de BorgBackup (datenoj por sekurkopioj iros rekte ĉi tie).
La principo de funkciado estas, ke apartaj volumoj estas kreitaj por ĉiu servilo por la BorgBackup-deponejoj, kie datumoj de la batalserviloj iros. La deponejoj funkcias en nura aldona reĝimo, kiu forigas la eblecon intencite forigi datumojn, kaj pro deduplikado kaj perioda purigado de deponejoj de malnovaj sekurkopioj (jaraj kopioj restas, ĉiumonate dum la lasta jaro, ĉiusemajne dum la lasta monato, ĉiutage por la pasintsemajne, eble en specialaj kazoj - ĉiuhore por la lasta tago: entute 24 + 7 + 4 + 12 + ĉiujare - proksimume 50 ekzempleroj por ĉiu servilo).
BorgBackup-deponejoj ne ebligas nuran reĝimon; anstataŭe, ForcedCommand en .ssh/authorized_keys estas uzata kiel ĉi tio:
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.......La specifita vojo enhavas envolvaĵskripton supre de borg, kiu, krom lanĉi la binaron kun parametroj, aldone komencas la procezon de restarigo de la rezerva kopio post kiam la datumoj estas forigitaj. Por fari tion, la envolvaĵa skripto kreas etikeddosieron apud la responda deponejo. La lasta sekurkopio farita estas aŭtomate restarigita al la responda logika volumeno post kiam la datumpleniga procezo estas finita.
Ĉi tiu dezajno ebligas al vi periode purigi nenecesajn sekurkopiojn, kaj ankaŭ malhelpas batalservilojn forviŝi ion ajn sur la rezerva stokadservilo.
Rezerva Procezo
La iniciatinto de la sekurkopio estas la dediĉita servilo aŭ VPS mem, ĉar ĉi tiu skemo donas pli da kontrolo de la rezerva procezo fare de ĉi tiu servilo. Unue, momentfoto de la stato de la aktiva radika dosiersistemo estas prenita, kiu estas muntita kaj alŝutita uzante BorgBackup al la rezerva stokadservilo. Post kiam datumkapto estas finita, la momentfoto estas malmuntita kaj forigita.
Se ekzistas malgranda datumbazo (ĝis 1 GB por ĉiu retejo), oni faras datumbazan rubejon, kiu estas konservita en la taŭga logika volumo, kie troviĝas la resto de la datumoj por la sama retejo, sed tiel ke la rubejo estas. ne alirebla per la retservilo. Se la datumbazoj estas grandaj, vi devus agordi "varman" forigon de datumoj, ekzemple, uzante xtrabackup por MySQL, aŭ labori kun WAL kun archive_command en PostgreSQL. En ĉi tiu kazo, la datumbazo estos restarigita aparte de la retejo-datumoj.
Se ujoj aŭ virtualaj maŝinoj estas uzataj, vi devus agordi qemu-guest-agent, CRIU aŭ aliajn necesajn teknologiojn. En aliaj kazoj, pliaj agordoj plej ofte ne estas bezonataj - ni simple kreas momentfotojn de logikaj volumoj, kiuj tiam estas prilaboritaj sammaniere kiel momentfoto de la stato de la radika dosiersistemo. Post kiam la datumoj estas prenitaj, la bildoj estas forigitaj.
Plia laboro estas farita sur la rezerva stoka servilo:
- la lasta sekurkopio farita en ĉiu deponejo estas kontrolita,
- la ĉeesto de marka dosiero estas kontrolita, indikante ke la datumkolekta procezo estas finita,
- la datenoj estas vastigitaj al la ekvivalenta loka volumeno,
- la etikedo dosiero estas forigita
Procezo de reakiro de servilo
Se la ĉefa servilo mortas, tiam simila dediĉita servilo estas lanĉita, kiu ekfunkciigas de iu norma bildo. Plej verŝajne la elŝuto okazos tra la reto, sed la datumcentra teknikisto instalanta la servilon povas tuj kopii ĉi tiun norman bildon al unu el la diskoj. La elŝuto okazas en RAM, post kio komenciĝas la reakiro:
- peto estas farita por ligi blokan aparaton per iscsinbd aŭ alia simila protokolo al logika volumeno enhavanta la radikan dosiersistemon de la forpasinta servilo; Ĉar la radika dosiersistemo devas esti malgranda, ĉi tiu paŝo devas esti finita en kelkaj minutoj. La ekŝargilo ankaŭ estas restarigita;
- la strukturo de lokaj logikaj volumoj estas rekreita, logikaj volumoj estas alkroĉitaj de la rezerva servilo uzante la dm_clone-kernan modulon: datumreakiro komenciĝas, kaj ŝanĝoj estas skribitaj tuj al lokaj diskoj.
- ujo estas lanĉita kun ĉiuj disponeblaj fizikaj diskoj - la funkcieco de la servilo estas plene restarigita, sed kun reduktita rendimento;
- post kiam datuma sinkronigo estas finita, la logikaj volumoj de la rezerva servilo estas malkonektitaj, la ujo estas malŝaltita, kaj la servilo estas rekomencita;
Post rekomenco, la servilo havos ĉiujn datumojn, kiuj estis tie kiam la sekurkopio estis kreita, kaj ankaŭ inkluzivos ĉiujn ŝanĝojn, kiuj estis faritaj dum la restarigo.
Aliaj artikoloj en la serio
Rezerva Parto 7: Konkludoj
Mi invitas vin diskuti la proponitan opcion en la komentoj, dankon pro via atento!
fonto: www.habr.com