Ang VPN server na nagbo-boot mula sa read-only na image at nagtatago ng runtime state nito sa tmpfs ay totoo at kapaki-pakinabang na disenyo. Madali rin itong ilarawan bilang walang log, na hindi pinatutunayan ng disenyo. Ang lokasyon ng imbakan ang nagtatakda kung saan nakatira ang isang kopya; ang pagkolekta at pagpapanatili ang nagtatakda kung may rekord man, at ang reboot ay nakakaapekto lamang sa una. Ang paghihiwalay ng dalawang ito ang buong pagsusuri.

Magsimula sa paglilista ng bawat prosesong makakapagsulat ng estado: ang daemon, ang serbisyo ng pagpapatunay, ang journal, anumang monitoring agent at ang mga tool sa pamamahala.

Magkaibang tanong ang imbakan at pagkolekta

Bawat manunulat ay may sariling destinasyon at sariling patakaran. Ang VPN daemon ay nagsusulat ng mga status file, ang backend ng pagpapatunay ay nagsusulat ng mga kaganapan sa account, ang journal ay nangongolekta ng output ng mga serbisyo, at ang monitoring agent ay nagpapadala ng mga sukatan sa ibang lugar nang lubusan. Ang disenyong nagpapawala sa isa sa mga ito sa reboot ay walang sinabi tungkol sa tatlo pang natitira. Sundan ang bawat manunulat hanggang sa destinasyon nito at itala kung ang destinasyong iyon ay nasa makina man.

Ang mga file na partikular sa aplikasyon, na-upload na diagnostics at panlabas na serbisyo ay nangangailangan ng parehong pagtrato. Ang kawalan ng pamilyar na lokal na log ay hindi nagpapatunay na walang rekord ng koneksyon o account saanman; pinatutunayan nito na hindi mo pa natagpuan kung saan sila pumupunta.

Ang tmpfs ay hindi garantiya

Ang Linux tmpfs ay hindi pisikal na RAM disk. Malinaw sa dokumentasyon ng kernel na ang mga pahina ay maaaring isulat sa swap kapag pinapayagan ito ng mount, kaya ang isang tmpfs file ay maaaring makarating sa disk nang hindi kailanman kinopya ng aplikasyon doon. Ipinapakita ng mount kung may tmpfs na sinusuportahan ng swap na ginagamit, at ang ibang memory filesystem ay kumikilos nang iba pa. Basahin ang tunay na mga opsyon sa mount sa halip na ipagpalagay na ang landas sa ilalim ng /run ay nangangahulugan ng pagiging pabagu-bago.

Pagkatapos, ilista ang mga bagay na nakakaligtas sa reboot sa mga paraang nakakalimutan ng mga tao: isang permanenteng upper layer, nakakabit na storage, mga hibernation image, crash dump at mga infrastructure snapshot ng buong VM. Ang bawat isa ay posibleng destinasyon para sa estadong inakala mong panandalian. Ang listahang iyon ay isang bagay na dapat suriin, hindi isang pag-aangkin na bawat host ay mayroong lahat.

Ang Journald ay may dalawang destinasyon at isang forwarder

Maayos na inilalarawan ng Journald ang paghihiwalay. Ang pabagu-bagong imbakan ay nagtatago ng mga entry sa ilalim ng /run/log/journal, ang permanente sa ilalim ng /var/log/journal, at ang awtomatikong mode ay pumipili sa pagitan ng dalawa; ang mode na umiiral ay nagmumula sa tumatakbong sistema at hindi sa paglalarawan ng image. Ang paglipat sa pabagu-bago ay hindi nagbubura ng naisulat nang permanente. Ang pagpapasa ay hiwalay ding channel: kahit ang setting ng imbakan na walang itinatago nang lokal ay maaaring maghatid ng mga mensahe sa ibang target.

Basahin ang umiiral na mode mula sa journal mismo o sa configuration file nito, pagkatapos ay hiwalay na suriin ang mga target ng pagpapasa, dahil ang isang setting ay hindi kinokontrol ang isa.

Ano ang dapat makaligtas sa reboot

Ang runtime na walang estado ay sumusuporta sa paulit-ulit na pagpapalit, at kailangan nito ng sadyang mga pinagmumulan para sa configuration, awtorisasyon at materyal sa pagbawi na hindi kayang imbentuhin ng serbisyo. Ang pagkawala ng tanging gumaganang estado ng pagpapatala o pagbawi para mawala ang mga lokal na sulat ay masamang kalakalan, at karaniwan. Magpasya kung ano ang dapat makaligtas nang sadya, pagkatapos ay i-verify na nakakaligtas ito.

Ang parehong pangangatwiran ay naaangkop sa mga operational record. Magpasya kung aling mga kaganapan ang tunay na kailangan ng seguridad at pamamahala ng serbisyo, na may makatarungang saklaw at pagpapanatili, at bawasan ang iba pa. Ang pagbawas ay hindi kapareho ng pag-off ng lahat ng diagnostics.

Ihambing ang umiiral na configuration ng imbakan at pagpapasa sa ilang hindi nakakapinsalang kaganapan, pagkatapos ay i-reboot o palitan ang makina at suriing muli kung ano ang natira at saan naibalik ng serbisyo ang estado nito.

Kaugnay na mga artikulo