Ինչպես պլանավորել լուռ, ցածր էներգիայի VPN սերվեր, որը միշտ միացված է

Պարապ վիճակը այն վիճակն է, որտեղ տնային VPN արկղն անցկացնում է իր կյանքի համարյա ամբողջ մասը, ուստի հենց այն արժե չափել։ Նույն մեքենան դեռ պետք է պատասխանի միացմանը, մատուցի ֆայլ և ավարտի պահուստավորումը, քանի դեռ թունելը բարձրացված է, և այս երեք աշխատանքները տարբեր ուղղություններով են քաշում։ Լռությունը, ցածր էներգիան և մշտական հասանելիությունը առանձին հատկություններ են, և բնութագրերի թերթիկը դրանցից ոչ մեկը չի նկարագրում։ Ստորև բերված ստուգումները հերթականությամբ անցնելը թույլ չի տալիս, որ սարքավորման որոշումը վեց ամիս անց դառնա վերակառուցում։

Սկսեք դերերից, ոչ թե մասերից

Գրեք յուրաքանչյուր աշխատանք, որը արկղը պետք է կատարի, երբ ոչ ոք չի հետևում։ WireGuard կամ OpenVPN դարպասը, ֆայլերի համօգտագործումը, պահուստավորման թիրախը և ինդեքսավորման աշխատանքը տարբեր մշտական ծախսեր ունեն, և բոլոր չորսը կատարող մեքենան շատ ավելի բարձր հատակ ունի, քան միայն առաջինը կատարողը։ Պարապ սպառումը այդ հատակների գումարն է, ոչ թե դրանց միջինը։ Այդ պատճառով նույն սենյակում երկու արկղ, որոնք երկուսն էլ նկարագրվում են որպես ցածր էներգիայի, կարող են տարբերվել երեք անգամ։

Վաղ որոշումը, թե արդյոք տվյալները ապրում են թունելի հետ նույն հոսթում, սահմանափակում է մնացած ամեն ինչ։ Առանձին հոսթերը նշանակում են երկու պարապ սպառում, բայց դարպաս, որը արթուն է մնում, մինչ պահեստը քնում է, իսկ մեկ հոսթը նշանակում է մեկ սպառում և մեկ ձախողման տիրույթ։ Երկուսն էլ սխալ չեն, բայց պատասխանը պետք է գրվի մինչև մասերի ցանկի գոյությունը։

Չափեք ամբողջ արկղը երեք վիճակում

Վարդակի և սնուցման աղբյուրի միջև պատի հաշվիչը այստեղ միակ ազնիվ գործիքն է, որովհետև այն ներառում է փոխակերպման կորուստները, սկավառակի պտտումը և ձեր մոռացած յուրաքանչյուր USB սարք։ Գրանցեք երեք թիվ՝ պարապ՝ թունելը բարձրացված և ուրիշ ոչինչ չաշխատող, նույն արկղը իրական հեռավոր փոխանցման ժամանակ և արկղը պլանավորված պահուստավորման ընթացքում։

Ծրագրային հաշվիչները օգնում են բացատրել պատի ցուցմունքը, բայց չեն փոխարինում այն։ RAPL ինտերֆեյսը հաղորդում է փաթեթի և հիշողության տիրույթի էներգիան, ինչը բացառում է սնուցման կորուստները և 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}'

Աղմուկը նույն վերաբերմունքի կարիքն ունի։ Առանց օդափոխիչների պատյանը հեռացնում է մեկ աղբյուր և թողնում կոշտ սկավառակը, սնուցումը և կոճերի բզզոցը, ուստի լսեք պահուստավորման ընթացքում, ոչ թե մուտքի էկրանին։ Ջերմաստիճանը նույն փուլի մասն է՝ կարդացեք սենսորները մշտական ծանրաբեռնվածության տակ և երբեք չանջատեք ջերմային պաշտպանությունը՝ արկղը ավելի լուռ դարձնելու համար։

Վատտերը դարձրեք տարվա, որը կարող եք համեմատել

Մշտական սպառումը էներգիայի է վերածվում մեկ բազմապատկմամբ, և մեկ անգամ անելը թույլ չի տալիս, որ տարեկան ծախսը անակնկալ դառնա։ Ամբողջ տարվա ընթացքում պատկերավոր 11 W միջինը հաշվարկվում է այսպես։

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

Այդ թիվը թվաբանություն է, ոչ թե ձեր արկղի չափում, և այն սակագինը, որով բազմապատկում եք, պատասխանը տեղափոխում է ավելի, քան մի քանի վատտ։ Հաշվարկը օգտակար է երկու նախագիծ համեմատելու համար՝ պարապ 6 W դարպասը 15 W-ի դեմ որոշում է, որին կարող եք գին դնել։ Պրոցեսորի անվանական հզորությունը այդ թիվը չէ, որովհետև այն նկարագրում է ծանրաբեռնված փաթեթ, ոչ թե հանգստի մեջ համակարգ։ Օգտագործեք պատի հաշվիչի միջինը տեղական սակագնի հետ և արդյունքը նշեք որպես գնահատական։

Որոշեք՝ արդյոք քունը թույլատրված է

Քունը խնայում է ամենաշատ էներգիան և կոտրում է ամենաշատ ենթադրությունները։ Քնած հոսթը չի կարող ընդունել այն մուտքային միացումը, որը կարթնացնի իրեն, և հաճախորդի keepalive-ը դա չի փոխում, և միայն նույն LAN-ում մշտապես միացված սարքը կարող է ուղարկել wake-on-LAN փաթեթ։

Եթե թունելը պետք է հասանելի լինի ցանկացած ժամի, քունը համարեք քաղաքականությամբ անջատված և գրեք դա կառուցման նշումներում։ Թիրախները քողարկելը կոպիտ է, բայց այն բացահայտ է և փաթեթների թարմացումներին դիմանում է ավելի լավ, քան սովորությունը։

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

Wake-on-LAN-ը արժանի է իր տողին այդ նշումներում, որովհետև այն ձախողվում է լուռ։ Ֆունկցիան պետք է միացվի որոնվածում, աշխատում է միայն որոշ ինտերֆեյսների վրա և պահանջում է արդեն արթուն սարք՝ փաթեթն ուղարկելու համար։ Փորձարկեք այն նախքան դրա վրա հույս դնելը, ոչ թե ճամփորդությունից հետո։

Ապացուցեք այն ծանրաբեռնվածության տակ, որը նա իսկապես կտեսնի

Վերջին ստուգումն այն է, որը մարդիկ բաց թողնում են՝ գործարկեք նախատեսված ծանրաբեռնվածությունը և մեկ ժամ հետևեք արկղին։ Հեռավոր փոխանցումը, պահուստավորումը և ինդեքսի վերակառուցումը միաժամանակ ցույց կտան՝ արդյոք հովացումը, կապը և պահեստը կարող են կրել ձեր ընտրած դերերի համակցությունը։

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

Նույն պատուհանում հետևեք նաև մուտքի կապին, որովհետև վերև հոսքի թողունակությունը սովորաբար սահմանափակում է հեռավոր թողունակությունը շատ ավելի վաղ, քան պրոցեսորը։ Եթե թունելը հագեցվում է պրոցեսորի կարող էնկրիպտելու մի մասում, ավելի արագ չիպը բացարձակապես ոչինչ չի գնում։