Një runtime VPN në RAM nuk thotë asgjë për regjistrat

Një server VPN që niset nga një imazh vetëm-lexim dhe mban gjendjen e ekzekutimit në tmpfs është një dizajn real dhe i dobishëm. Është gjithashtu e lehtë ta përshkruash si pa regjistra, gjë që dizajni nuk e vërteton. Vendi i ruajtjes përcakton ku jeton një kopje; mbledhja dhe mbajtja përcaktojnë nëse ekziston fare një regjistrim, dhe rinisja ndikon vetëm në të parën. Ndarja e këtyre dyjave është i gjithë shqyrtimi.

Filloni duke listuar çdo proces që mund të shkruajë gjendje: demoni, shërbimi i autentikimit, ditari, çdo agjent monitorimi dhe mjetet e menaxhimit.

Ruajtja dhe mbledhja janë pyetje të ndryshme

Çdo shkrues ka destinacionin dhe politikën e vet. Demon i VPN shkruan skedarë gjendjeje, backend-i i autentikimit shkruan ngjarje llogarie, ditari mbledh daljen e shërbimeve dhe një agjent monitorimi dërgon metrikat diku krejt tjetër. Një dizajn që bën një prej tyre të zhduket në rinisje nuk ka thënë asgjë për tre të tjerët. Ndiqni çdo shkrues deri në destinacionin e tij dhe vini re nëse ai destinacion është fare në makinë.

Skedarët specifikë të aplikacionit, diagnostika e ngarkuar dhe shërbimet e jashtme kanë nevojë për të njëjtin trajtim. Mungesa e një ditari lokal të njohur nuk provon se regjistrimet e lidhjes ose të llogarisë nuk ekzistojnë askund; provon se nuk e keni gjetur ende ku shkojnë.

tmpfs nuk është garanci

Linux tmpfs nuk është disk fizik RAM. Dokumentacioni i kernelit është i qartë se faqet mund të shkruhen në swap kur montimi e lejon, kështu që një skedar tmpfs mund të arrijë në një disk pa e kopjuar aplikacioni kurrë atje. mount tregon nëse është në lojë një tmpfs i mbështetur nga swap, dhe sistemet e tjera të skedarëve në memorie sillen përsëri ndryshe. Lexoni opsionet reale të montimit në vend që të supozoni se një shteg nën /run nënkupton paqëndrueshmëri.

Më pas inventarizoni gjërat që i mbijetojnë një rinisje në mënyra që njerëzit i harrojnë: një shtresë e sipërme e përhershme, ruajtje e lidhur, imazhe hibernimi, dump-e përplasjesh dhe pamje infra-strukture të të gjithë VM-së. Secila është një destinacion i mundshëm për gjendje që ju e mendonit efemere. Ai listë është diçka për t'u kontrolluar, jo një pretendim se çdo host i ka të gjitha.

Journald ka dy destinacione dhe një përcjellës

Journald e ilustron bukur ndarjen. Ruajtja e paqëndrueshme mban zërat nën /run/log/journal, ajo e përhershme nën /var/log/journal, dhe modaliteti automatik zgjedh midis tyre; modaliteti në fuqi vjen nga sistemi që punon, jo nga përshkrimi i imazhit. Kalimi në të paqëndrueshme nuk fshin atë që është shkruar tashmë përhershëm. Edhe përcjellja është kanal më vete: edhe një konfigurim ruajtjeje që nuk mban asgjë lokalisht mund t'u dorëzojë mesazhet një tjetër objektivi.

Lexoni modalitetin në fuqi nga vetë ditari ose nga skedari i konfigurimit të tij, më pas kontrolloni veçmas objektivat e përcjelljes, sepse një konfigurim nuk kontrollon tjetrin.

Çfarë duhet t'i mbijetojë një rinisje

Një runtime pa gjendje mbështet zëvendësimin e përsëritshëm, dhe ka nevojë për burime të qëllimshme për konfigurimin, autorizimin dhe materialin e rikuperimit që shërbimi nuk mund ta sajojë. Humbja e gjendjes së vetme funksionale të regjistrimit ose revokimit që shkrimet lokale të zhduken është një marrëveshje e keqe, dhe e zakonshme. Vendosni çfarë duhet të mbijetojë me qëllim, më pas verifikoni që e bën.

I njëjti arsyetim vlen për regjistrat operative. Vendosni cilat ngjarje kërkojnë vërtet siguria dhe menaxhimi i shërbimit, me një shtrirje dhe mbajtje të arsyeshme, dhe minimizoni pjesën tjetër. Minimizimi nuk është e njëjta gjë me çaktivizimin e çdo diagnostike.

Krahasoni konfigurimin në fuqi të ruajtjes dhe përcjelljes me disa ngjarje të pafajshme, më pas rinisni ose zëvendësoni makinën dhe kontrolloni përsëri çfarë mbeti dhe nga erdhi shërbimi për të rikuperuar gjendjen e tij.