VPS և cloud provider-ներ

01Հավելված host անելու չորս ձև

Hosting-ի մասին մտածիր բնակարանի պես։ Shared hosting-ը սենյակ է ընդհանուր բնակարանում․ էժան է և կառավարվում է քո փոխարեն, բայց ռեսուրսները կիսում ես հարյուրավոր կայքերի հետ, չես կարող սեփական ծրագրեր տեղադրել, և մեկ աղմկոտ հարևանը քեզ դանդաղեցնում է։ Այն աշխատում է պարզ PHP կայքերի համար։ VPS-ը քո սեփական բնակարանն է՝ վիրտուալ մեքենա երաշխավորված CPU-ով, RAM-ով և սկավառակով և լրիվ root հասանելիությամբ, որտեղ դու ես պատասխանատու ներսի ամեն ինչի համար։ Managed պլատֆորմը (PaaS), ինչպես Vercel-ը, Render-ը, Fly.io-ն, Railway-ն կամ Laravel Cloud-ը, սպասարկվող բնակարան է․ դու push ես անում կոդը, իսկ այն հոգում է սերվերները, scaling-ը և TLS-ը՝ ավելի բարձր գնով մեկ ռեսուրսի համար և պլատֆորմի սահմանափակումներով։ Hyperscale cloud-ը (AWS, Google Cloud, Azure) ամբողջ քաղաք է՝ վիրտուալ մեքենաներ գումարած managed տվյալների բազաներ, queue-եր, storage և ցանց, շատ ճկուն և շատ բարդ։

• Shared hosting՝ ամենաէժանը, ամենաքիչ վերահսկողությունը։ Լավ է brochure կայքերի և փոքր WordPress տեղադրումների համար։
• VPS՝ լրիվ վերահսկողություն ցածր գնով․ անվտանգությունը, թարմացումները և backup-ները քոնն են։
• Managed պլատֆորմ՝ ամենաարագ թողարկումը, վճարում ես հարմարավետության համար, սահմանափակ վերահսկողություն։
• Hyperscale cloud՝ ամեն ինչ հասանելի է, բայց գինն ու կոնֆիգուրացիան իրական փորձառություն են պահանջում։

02Provider-ի ընտրություն

VPS hosting-ի համար հայտնի տարբերակներն են DigitalOcean-ը (droplet-ներ, պարզ UI, լավ փաստաթղթեր, managed տվյալների բազաներ և object storage), Hetzner-ը (գին-արտադրողականության շատ ուժեղ հարաբերակցություն, data center-ներ Եվրոպայում և ԱՄՆ-ում), Vultr-ը, Linode-ը (այժմ Akamai) և OVHcloud-ը։ AWS Lightsail-ը առաջարկում է պարզ VPS պլաններ AWS-ի ներսում։ Մեծ cloud-երը իմաստ ունեն, երբ քեզ պետք են կոնկրետ managed ծառայություններ, compliance սերտիֆիկացումներ, շատ region-ներ, կամ ընկերությունդ արդեն այնտեղ է աշխատում։ Համեմատելիս նայիր ամսական գնից այն կողմ․ ստուգիր data center-ների տեղերը, ներառված bandwidth-ը և դրանից ավելիի գինը, snapshot-ների և backup-ների որակը, արդյոք կա cloud firewall և private networking, managed տվյալների բազայի և object storage-ի տարբերակները, API-ի և Terraform-ի աջակցությունը և ինչպես է արձագանքում support-ը։ Գները փոխվում են, ուստի համեմատիր ընթացիկ գնային էջերը, ոչ թե հին blog post-երը։

• Տեղադրություն՝ մոտ քո օգտատերերին․ հաշվի առ տվյալների պահման կանոնները, ինչպես GDPR-ը։
• Ցանց՝ ներառված traffic, egress-ի գին, IPv6, DDoS պաշտպանություն։
• Լրացուցիչներ՝ cloud firewall, private ցանց, snapshot-ներ, backup-ներ, object storage, managed DB։
• Գործառնություններ՝ API, CLI, Terraform provider, status-ի պատմություն և support-ի որակ։

03Չափավորում և region

Սկսիր փոքրից և չափիր․ VPS-ը հետագայում resize անելը հեշտ է, և provider-ների մեծ մասը թույլ է տալիս մեծացնել րոպեների ընթացքում։ nginx-ով և PHP-ով կամ Node-ով փոքր կայքը հանգիստ աշխատում է 1-ից 2 vCPU-ի և 2 GB RAM-ի վրա։ Նույն մեքենայի վրա ավելացրու տվյալների բազա, Redis և queue worker-ներ, և 4 GB-ը կամ ավելին ավելի անվտանգ սկիզբ է։ Սովորաբար առաջին սահմանը հիշողությունն է, ոչ թե CPU-ն։ Shared vCPU պլանները էժան են և նորմալ վեբ հավելվածների մեծ մասի համար, dedicated vCPU պլանները կայուն արտադրողականություն են տալիս CPU-ծանր աշխատանքի համար։ Ընտրիր քո օգտատերերի մեծ մասին ամենամոտ region-ը, իրար հետ խոսող սերվերները պահիր նույն region-ում և հիշիր, որ Cloudflare-ի նման CDN-ը կարող է static ֆայլերը սպասարկել օգտատերերին մոտ ամենուր։ Մի քանի շաբաթ հետևիր load-ին, հիշողությանը և սկավառակին և resize արա տվյալների հիման վրա։

• Վեբ սերվերների մեծ մասում հիշողությունը սպառվում է CPU-ից առաջ․ պլանավորիր տվյալների բազայի և worker-ների համար։
• SSD կամ NVMe սկավառակ․ օգտատերերի upload-ները և backup-ները պահիր object storage-ում՝ հսկայական սկավառակի փոխարեն։
• Մեծացնելը սովորաբար հեշտ է, սկավառակը փոքրացնելը հաճախ՝ ոչ։

04Snapshot-ներ, backup-ներ և private networking

Snapshot-ը սերվերի սկավառակի ամբողջական image է մեկ պահին։ Այն կատարյալ է ռիսկային փոփոխություններից առաջ, որովհետև կարող ես ամբողջ մեքենան հետ վերադարձնել։ Provider-ի backup-ները պլանավորված snapshot-ներ են, սովորաբար ամենօրյա կամ ամենշաբաթյա՝ փոքր հավելավճարով։ Բայց երկուսն էլ գտնվում են նույն provider-ի մոտ, և աշխատող տվյալների բազայի disk snapshot-ը կարող է հետևողական չլինել։ Այդ պատճառով արա նաև հավելվածի մակարդակի backup-ներ, օրինակ՝ տվյալների բազայի dump, և պատճենիր դրանք սերվերից դուրս, իդեալում՝ այլ provider-ի կամ region-ի object storage։ Backup-ը հաշվվում է միայն այն բանից հետո, երբ հաջողությամբ restore ես արել այն։ Private networking-ը քո սերվերները միացնում է ներքին ցանցով, որը հասանելի չէ ինտերնետից, այնպես որ app սերվերը կարող է հասնել տվյալների բազային՝ առանց այն public բացելու։

• Snapshot՝ upgrade-ներից, migration-ներից և config-ի մեծ փոփոխություններից առաջ։
• Տվյալների բազայի dump-եր գումարած off-site պատճեններ․ հետևիր 3-2-1 գաղափարին (3 պատճեն, 2 կրիչ, 1 off-site)։
• Restore-ները պարբերաբար ստուգիր նոր սերվերի վրա։
• Սերվերների միջև տվյալների բազայի և cache-ի traffic-ի համար օգտագործիր private ցանցը։

05Ծախսերի վերահսկում

Cloud հաշիվները լուռ են աճում։ Սովորական արտահոսքերն են մոռացված սերվերները և test միջավայրերը, հին snapshot-ները և չմիացված volume-ները, չափազանց մեծ instance-ները, որոնք ոչ ոք resize չի արել, load balancer-ները և static IP-ները, որոնք այլևս չես օգտագործում, և ամենից առաջ ելքային traffic-ը (egress), որը մեծ cloud-երում վճարվում է ըստ գիգաբայթի և կարող է գերազանցել սերվերի գինը։ Առատ ներառված traffic-ով VPS provider-ը bandwidth-ծանր կայքերի համար հաճախ շատ ավելի էժան է։ Պարզ սովորություններն օգնում են․ սահմանիր billing alert, յուրաքանչյուր ռեսուրս tag արա կամ անվանիր ըստ նախագծի, ամեն ամիս դիտիր հաշիվը, ջնջիր այն, ինչ չես օգտագործում, և static asset-ների առջևում դիր CDN։ Շատ փոքր, կիսադատարկ սերվերները ավելի քիչ, ճիշտ չափի սերվերների մեջ միավորելը հաճախ միաժամանակ կրճատում է և՛ ծախսը, և՛ սպասարկումը։

• Billing alert-ներ և բյուջեներ յուրաքանչյուր հաշվի վրա։
• Ամսական մաքրում՝ հին snapshot-ներ, volume-ներ, IP-ներ, test սերվերներ։
• Հետևիր egress-ի գնին․ static ֆայլերը cache արա CDN-ում։
• Reserved կամ savings պլանների պարտավորվիր միայն կայուն, երկարաժամկետ workload-երի համար։

06Առաջին 10 րոպեն նոր սերվերի վրա

Նոր public սերվերը scan է արվում րոպեների ընթացքում, ուստի պաշտպանիր այն, մինչև որևէ բան deploy անելը։ Սերվերը ստեղծիր քո SSH key-ը ավելացրած, մուտք գործիր, թարմացրու փաթեթները, ստեղծիր քո սեփական sudo օգտատերը, երկրորդ տերմինալում հաստատիր, որ key login-ը աշխատում է այդ օգտատիրոջ համար, հետո անջատիր password-ի և root-ի մուտքը։ Միացրու firewall-ը միայն SSH-ով, HTTP-ով և HTTPS-ով և նույնը կրկնիր provider-ի cloud firewall-ում։ Միացրու անվտանգության ավտոմատ թարմացումները, տեղադրիր fail2ban, սահմանիր ժամային գոտին և hostname-ը, փոքր instance-ների վրա ավելացրու swap ֆայլ և արա մաքուր բազայի առաջին snapshot-ը։ Վերջում կարգավորիր monitoring-ը և սկավառակի alert-ը։ Յուրաքանչյուր քայլի հրամանները քննարկված են Linux-ի մյուս դասերում։

1ssh [email protected]                      # first login with your key
2apt update && apt full-upgrade -y
3adduser your_user && usermod -aG sudo your_user
4rsync -a --chown=your_user:your_user ~/.ssh /home/your_user/
5# New terminal: ssh [email protected] must work before continuing
6printf "PasswordAuthentication no\nPermitRootLogin no\n" > /etc/ssh/sshd_config.d/10-hardening.conf
7sshd -t && systemctl reload ssh
8ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
9apt install -y unattended-upgrades fail2ban
10dpkg-reconfigure -plow unattended-upgrades
11timedatectl set-timezone UTC && hostnamectl set-hostname web1

07Ինչ է իրականում vCPU-ն․ hypervisor-ներ, steal time և storage

VPS-ը վիրտուալ մեքենա է ֆիզիկական host-ի վրա, որը կիսվում է այլ հաճախորդների հետ և աշխատում է hypervisor-ի ներքո, ինչպես KVM-ն։ vCPU-ն սովորաբար host-ի core-ի մեկ hardware thread է, որը բաշխվում է բազմաթիվ guest-երի միջև։ Shared-CPU plan-երի դեպքում provider-ը ենթադրում է, որ ոչ բոլորն են միաժամանակ զբաղված․ երբ հարևաններդ զբաղված են, քո VM-ը սպասում է, և այդ սպասումը երևում է որպես steal time՝ st արժեքը top-ում և vmstat-ում։ Մի քանի տոկոսից բարձր կայուն steal-ը նշանակում է, որ վճարում ես CPU-ի համար, որը չես ստանում, և dedicated-CPU plan-ը կամ այլ host-ը լուծում է դա։ Storage-ն էլ է տարբերվում․ տեղական NVMe-ն արագ է և ցածր latency ունի, բայց կապված է host-ին, մինչդեռ ցանցային block volume-ները դիմանում են host-ի ձախողումներին և կարող են տեղափոխվել, բայց ունեն ավելի բարձր latency և IOPS սահմաններ՝ ըստ volume-ի չափի։ Իմանալը, թե որն ունես, բացատրում է benchmark-ի արդյունքները, որոնք այլապես անիմաստ են թվում։

1top -bn1 | head -5            # look at 'st' in the %Cpu(s) line
2vmstat 1 10                   # last column 'st' = steal
3lscpu | grep -E 'Model name|Thread|Hypervisor'
4systemd-detect-virt           # kvm, xen, microsoft...
5# Quick disk benchmark (apt install fio), on a test file, not a live DB
6fio --name=randread --rw=randread --bs=4k --size=1G --runtime=30 \
7    --ioengine=libaio --direct=1 --filename=/var/tmp/fio.test

08Սերվերները որպես կոդ․ cloud-init և վերակառուցելի մեքենաներ

Ամենահուսալի սերվերն այն է, որը կարող ես վերստեղծել րոպեների ընթացքում։ Գրեթե բոլոր provider-ները աջակցում են cloud-init-ը․ VM ստեղծելիս փոխանցում ես user-data փաստաթուղթ, և առաջին boot-ի ժամանակ այն ստեղծում է օգտատերեր, տեղադրում SSH key-եր, տեղադրում փաթեթներ և գործարկում հրամաններ։ Դա hardening-ի առաջին տասը րոպեն վերածում է ֆայլի, որը վերանայում ես և version-ավորում, ուստի յուրաքանչյուր նոր սերվեր սկսվում է նույնականորեն։ Terraform-ի կամ OpenTofu-ի նման գործիքները մեկ մակարդակ վեր են գնում և provider-ի API-ի միջոցով նկարագրում են հենց սերվերները, firewall-ները, volume-ները և DNS գրառումները, իսկ Ansible-ի նման կոնֆիգուրացիոն գործիքները կառավարում են մեքենայի ներսում ընթացիկ փոփոխությունները։ Նույնիսկ եթե երբեք ամբողջությամբ չավտոմատացնես, user-data-ն և գրավոր runbook-ը պահելը նշանակում է, որ կորած սերվերը անհարմարություն է, ոչ թե ճգնաժամ, քանի որ ոչ մի կարևոր բան գոյություն չունի միայն ինչ-որ մեկի հիշողության մեջ։

1#cloud-config
2users:
3  - name: your_user
4    groups: [sudo]
5    shell: /bin/bash
6    lock_passwd: true
7    ssh_authorized_keys:
8      - ssh-ed25519 AAAAC3...placeholder your_user@laptop
9ssh_pwauth: false
10disable_root: true
11package_update: true
12package_upgrade: true
13packages: [ufw, fail2ban, unattended-upgrades]
14runcmd:
15  - [ufw, allow, OpenSSH]
16  - [ufw, allow, 80/tcp]
17  - [ufw, allow, 443/tcp]
18  - [ufw, --force, enable]

09Availability փոքր բյուջեով․ RPO, RTO և single point of failure

Երկու թիվ availability-ի քննարկումները կոնկրետ են դարձնում։ RPO-ն (recovery point objective) այն է, թե որքան տվյալ կարող ես թույլ տալ կորցնել, ինչը սահմանում է backup-ների հաճախականությունը․ գիշերային dump-երը նշանակում են մինչև մեկ օրվա կորած պատվերներ։ RTO-ն (recovery time objective) այն է, թե որքան կարող ես անջատված լինել, ինչը սահմանում է, թե որքանը պետք է ավտոմատացված լինի։ Մեկ VPS-ը single point of failure է, և դա հաճախ ընդունելի է, եթե RPO-ն և RTO-ն համաձայնեցված և փորձարկված են։ Էժան բարելավումները գալիս են առաջինը՝ ավելի հաճախակի dump-եր կամ binlog-ի կամ WAL-ի շարունակական արխիվացում object storage, reserved կամ floating IP, որը կարելի է տեղափոխել փոխարինող սերվերի վրա, չափավոր պահված DNS TTL-ներ և փորձարկված restore։ Load balancer-ի հետևում երկու app սերվեր գործարկելը օգնում է միայն այն ժամանակ, երբ database-ը, session-ները և upload-ներն այլևս մեկ մեքենայի վրա չեն։

• Համաձայնեցրու RPO-ն և RTO-ն բիզնեսի հետ՝ նախքան ճարտարապետություն ընտրելը։
• Floating կամ reserved IP-ն թույլ է տալիս փոխել սերվերները՝ առանց DNS-ին սպասելու։
• Restore-ի վարժանքները գրավոր RTO-ն վերածում են չափվածի։

10Մասշտաբավորման ճանապարհը մեկ VPS-ից

Մասշտաբավորիր քայլերով և միայն այն ժամանակ, երբ չափումները դա պահանջում են։ Առաջին քայլը ուղղահայացն է՝ ավելի մեծ plan, որը րոպեներ է տևում և ոչինչ չի փոխում հավելվածում։ Երկրորդ քայլը բաժանումն է՝ database-ը տեղափոխիր իր սեփական սերվեր կամ managed database private network-ում, որպեսզի հավելվածը և տվյալները դադարեն մրցել հիշողության համար, իսկ upload-ները տեղափոխիր object storage։ Երրորդ քայլը հորիզոնականն է՝ մի քանի նույնական app սերվեր load balancer-ի հետևում։ Դա պահանջում է stateless app սերվերներ՝ session-ները և cache-ը Redis-ում կամ database-ում, ֆայլերը object storage-ում, պլանավորված job-երը ճիշտ մեկ node-ի վրա և deploy-ներ, որոնք համաձայնեցված թարմացնում են բոլոր node-երը։ Չորրորդ քայլը read replica-ներն են, queue-երը դանդաղ աշխատանքի համար և CDN-ը ստատիկ բովանդակության համար։ Յուրաքանչյուր քայլ ավելացնում է ծախս և օպերացիոն աշխատանք, ուստի լավ կարգավորված մեկ սերվերը հաճախ ավելի հեռու է գնում, քան մարդիկ սպասում են։

• Նախ ուղղահայաց, հետո բաժանիր database-ը, հետո՝ հորիզոնական։
• Հորիզոնական մասշտաբավորումը պահանջում է stateless app սերվերներ։
• Համոզվիր, որ cron-ը և scheduler-ները աշխատում են միայն մեկ node-ի վրա։