Paano magplano ng tahimik, mababang-konsumo at laging-bukas na VPN server

Ang idle ang estadong pinagdadaanan ng halos buong buhay ng isang home VPN box, kaya iyon ang estadong dapat sukatin. Kailangan pa ring sagutin ng parehong makina ang isang koneksyon, maghatid ng file at tapusin ang isang backup habang bukas ang tunnel, at ang tatlong gawaing ito ay humihila sa magkakaibang direksyon. Tahimik, mababang konsumo at laging maabot ay magkakahiwalay na katangian, at walang isa sa mga ito ang inilalarawan ng spec sheet. Kung dadaanin ang mga pagsusuri sa ibaba nang sunod-sunod, hindi magiging muling pagtatayo ang desisyon sa hardware makalipas ang anim na buwan.

Magsimula sa mga papel, hindi sa mga piyesa

Isulat ang bawat gawain na dapat gawin ng box habang walang nakatingin. Ang isang WireGuard o OpenVPN gateway, file sharing, backup target at indexing job ay may magkakaibang palagiang gastos, at ang isang makinang gumagawa ng lahat ng apat ay may mas mataas na sahig kaysa sa gumagawa lamang ng una. Ang konsumo habang idle ay ang kabuuan ng mga sahig na iyon, hindi ang average. Kaya ang dalawang box na parehong inilalarawan bilang mababang-konsumo ay maaaring magkaiba nang tatlong beses sa isang silid.

Ang maagang pagpapasya kung ang data ay nakatira sa parehong host ng tunnel ay naglilimita sa lahat ng iba. Ang magkahiwalay na host ay nangangahulugan ng dalawang idle consumption, ngunit isang gateway na gising habang natutulog ang storage; ang isang host ay isang konsumo at isang domain ng pagkabigo. Walang mali sa dalawa, ngunit kailangang isulat ang sagot bago maging ang listahan ng piyesa.

Sukatin ang buong box sa tatlong estado

Ang wall meter sa pagitan ng saksakan at power supply ang tanging tapat na instrumento dito, dahil kasama nito ang mga pagkalugi sa conversion, pag-ikot ng disk at bawat USB device na nakalimutan mo. Itala ang tatlong numero: idle na bukas ang tunnel at walang ibang tumatakbo, ang parehong box sa ilalim ng tunay na remote transfer, at ang box habang naka-iskedyul ang backup.

Nakakatulong ang mga software counter na ipaliwanag ang reading ng wall meter ngunit hindi nito ito pinapalitan. Iniuulat ng RAPL interface ang enerhiya ng package at memory domain, na hindi kasama ang pagkalugi ng power supply at lahat ng nakakabit sa USB.

read -r a < /sys/class/powercap/intel-rapl:0/energy_uj; sleep 60; read -r b < /sys/class/powercap/intel-rapl:0/energy_uj
awk -v a="$a" -v b="$b" 'BEGIN{printf "package average: %.1f W\n", (b-a)/60/1000000}'

Kailangan din ng ingay ang parehong pagtrato. Tinatanggal ng case na walang fan ang isang pinagmulan at iniiwan ang hard disk, power supply at sipol ng coil, kaya makinig habang nag-backup at hindi sa login prompt. Kasama sa parehong ikot ang temperatura: basahin ang mga sensor sa ilalim ng tuloy-tuloy na load, at huwag kailanman patayin ang thermal protection para maging mas tahimik ang box.

Gawing taon na maihahambing ang watts

Ang tuloy-tuloy na konsumo ay nagiging enerhiya sa isang multiplikasyon, at ang paggawa nito nang isang beses ay pumipigil sa taunang gastos na maging sorpresa. Ang halimbawang average na 11 W sa loob ng buong taon ay kinakalkula nang ganito.

awk 'BEGIN{printf "%.1f kWh/year at 11 W\n", 11*24*365/1000}'

Ang numerong iyon ay aritmetika, hindi sukat ng iyong box, at ang tariff na ipinaparami mo ay naglilipat ng sagot nang higit sa ilang watts. Kapaki-pakinabang ang kalkulasyon sa paghahambing ng dalawang disenyo: ang gateway na 6 W habang idle laban sa 15 W ay desisyong mabibigyan mo ng presyo. Ang rate na watts ng processor ay hindi ang numerong iyon, dahil inilalarawan nito ang package sa ilalim ng load at hindi ang sistemang nagpapahinga. Gamitin ang average ng wall meter kasama ang lokal na tariff, at markahan ang resulta bilang estimate.

Magpasya kung pinapayagan ang pagtulog

Ang pagtulog ay pinakatipid sa enerhiya at pinakamaraming sinisirang palagay. Ang natutulog na host ay hindi makakatanggap ng papasok na koneksyon na gigising dito, at hindi iyon binabago ng client keepalive; tanging device na laging bukas sa parehong LAN ang makapagpapadala ng wake-on-LAN packet.

Kung kailangang maabot ang tunnel sa kahit anong oras, ituring na hindi pinagana ng patakaran ang pagtulog at isulat iyon sa build notes. Ang pagtatakip sa mga target ay bastos, ngunit tahasan ito at mas nakakalampas sa mga update ng package kaysa sa ugali.

systemctl status sleep.target suspend.target
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemd-inhibit --list

Ang Wake-on-LAN ay dapat magkaroon ng sariling linya sa mga note na iyon dahil tahimik itong nabibigo. Dapat i-enable ang feature sa firmware, gumagana lamang sa ilang interface, at kailangang may device na gising na para magpadala ng packet. Subukan ito bago ka umasa, hindi pagkatapos ng isang biyahe.

Patunayan ito sa ilalim ng load na talagang makikita nito

Ang huling pagsusuri ang madalas laktawan: patakbuhin ang inilaan na load at panoorin ang box nang isang oras. Ang sabay na remote transfer, backup at muling pagbuo ng index ay magpapakita kung kaya ng cooling, link at storage ang piniling kombinasyon ng papel.

uptime
sensors | grep -E 'Core|Package|fan'
ss -s

Tingnan din ang access link sa parehong window, dahil karaniwang nililimitahan ng upstream bandwidth ang remote throughput bago pa man ang processor. Kung ang tunnel ay umabot sa saturation sa isang maliit na bahagi ng kayang i-encrypt ng CPU, walang nabibili ang mas mabilis na chip.