ენა
ორი შეთავაზება ერთნაირი რაოდენობის core-ით, RAM-ითა და დისკით შეიძლება სრულიად განსხვავებულ არჩევანს ნიშნავდეს. განსხვავება ხშირად სპეციფიკაციის მოკლე ხაზში არ ეტევა: რა ტიპის მოთხოვნას ასრულებს CPU, რამდენი პროცესი ცხოვრობს მეხსიერებაში და რა მოხდება დისკის ან აპლიკაციის შეცდომის შემდეგ? Dedicated სერვერის კარგი მოთხოვნა ამ კითხვებზე პასუხით იწყება.
მოთხოვნის დასაწყისში დაწერეთ, რას ემსახურება სერვერი
ჩამოწერეთ აპლიკაციები, database engine, background jobs და ძირითადი გარე კავშირები. მიუთითეთ მომხმარებელთა ჩვეული და პიკური აქტივობა, batch სამუშაოს ხანგრძლივობა და მონაცემების ზრდა. დღის საშუალო CPU შეიძლება მშვიდი იყოს, თუმცა ღამის ანგარიშგება storage-ს ან RAM-ს მნიშვნელოვნად ტვირთავდეს.
გაარჩიეთ სამი ტიპი: CPU-bound სამუშაოს გამოთვლითი სიმძლავრე ზღუდავს; memory-bound პროცესს სამუშაო მონაცემებისთვის RAM აკლია; I/O-bound სისტემაში საცავის ოპერაციების მოლოდინია მნიშვნელოვანი. პრაქტიკაში რამდენიმე შეზღუდვა შეიძლება ერთდროულად მოქმედებდეს.
შეარჩიეთ ერთი მნიშვნელოვანი სამუშაო ციკლი და დაწერეთ მისი მიღების პირობა. მაგალითად, ღამის დამუშავება დილის დაწყებამდე უნდა დასრულდეს, ან ოპერატორის კონკრეტული მოქმედება შეთანხმებულ დროში უნდა დამუშავდეს. ეს მაგალითები მოთხოვნის ფორმას აჩვენებს. რეალური ვადა და დასაშვები შეცდომა თქვენს საქმიანობას უნდა მოერგოს; სერვერის ერთი დასახელება ასეთ შედეგს ვერ შეგპირდებათ.
შესყიდვის მოთხოვნაში მიუთითეთ, მონაცემი ახალი სისტემის ვარაუდიდან მოდის თუ უკვე მოქმედი აპლიკაციიდან. პირველ შემთხვევაში დატოვეთ საცდელი შემოწმების ადგილი. მეორე შემთხვევაში მოიტანეთ წარმომადგენლობითი პერიოდი, რადგან ერთ მშვიდ საათში აღებული საშუალო მაჩვენებელი შეიძლება დღიურ პიკს ვერ აღწერდეს. შედეგს ყოველთვის მიაყოლეთ თარიღი და გაზომვის პირობები.
პროცესორი: საშუალო დატვირთვის მიღმა
ბირთვების რაოდენობას დაუმატეთ პროცესორის თაობა, თითო ბირთვის წარმადობა, აპლიკაციის პარალელურობა და ლიცენზირების მოდელი. თანმიმდევრულ სამუშაოს ბევრი ბირთვი ავტომატურად ვერ დააჩქარებს. თითოეულ მოთხოვნას ერთი CPU core მუდმივად არ სჭირდება, ამიტომ ვიზიტორების რაოდენობა ბირთვების რაოდენობაზე პირდაპირ არ გადაიყვანოთ.
საწყისი მტკიცებულება უნდა იყოს საკუთარი workload-ის გაზომვა. Linux-ში ხელმისაწვდომი pressure metrics შეიძლება CPU, memory და I/O მოლოდინის შეფასებას დაეხმაროს, თუმცა მათი არსებობა kernel/config-ზეა დამოკიდებული. ერთ მაჩვენებელს პრობლემის საბოლოო მიზეზად ნუ ჩათვლით.
პროცესორის დაბალი საშუალო პროცენტი ყველა პროცესის სიმშვიდეს არ ნიშნავს. ერთდროულად შეიძლება ერთი მნიშვნელოვანი ნაკადი იტვირთებოდეს, სხვა ბირთვები კი თავისუფალი იყოს. მეორე მხრივ, ნელი მოთხოვნა შეიძლება საცავს ან გარე API-ს ელოდებოდეს. სასარგებლოა, ერთმანეთს დაუკავშიროთ კონკრეტული ოპერაცია, CPU-ის დაკვირვება და ლოდინის ნიშნები; მხოლოდ ერთი გრაფიკით რესურსის დამატება ძვირი ვარაუდია.
RAM საერთო ბიუჯეტია
შეაჯამეთ OS, აპლიკაციის პროცესები, მონაცემთა ბაზა, cache და ადმინისტრაციული ხელსაწყოები. თითო პროცესის პიკური მეხსიერება და ერთდროულად აქტიური პროცესები ცალ-ცალკე განსაზღვრეთ. database პარამეტრის ერთი მნიშვნელობა მისი მთლიანი მეხსიერების მოხმარების ტოლი ყოველთვის არ არის.
ჰიპოთეზური გარემოს სამუშაო მეხსიერებას 6 GiB სჭირდება. თუ მთლიან მოცულობაში 25% თავისუფალი რეზერვი გსურთ, გამოთვლაა 6 / (1 - 0.25) = 8 GiB. მხოლოდ 6-ის 25%-ით გაზრდა სხვა შედეგს იძლევა და მთლიან capacity-ში 25% თავისუფალ ნაწილს არ ტოვებს. რეალური peak ცალკე უნდა გაიზომოს.
მეხსიერების ჩანაწერში ერთი და იგივე რესურსი ორჯერ არ დაითვალოთ. თუ container-ის ლიმიტს წერთ, გაარკვიეთ, შიგნით ბაზის cache-იც შედის თუ მხოლოდ აპლიკაცია. თუ ერთ ჰოსტზე რამდენიმე სერვისია, მათ ერთდროულ მაქსიმუმებს დააკავშირეთ რეალური დროის მონაკვეთთან. ყველა ცალკეული პიკის მექანიკურად შეკრება შეიძლება ზედმეტად დიდი კონფიგურაციისკენ წაგიყვანოთ, მაგრამ ყველა პიკის იგნორირება - არასაკმარისისკენ.
წარმადობის მარაგი კონკრეტულ მიზეზს დაუკავშირეთ: სეზონურ ზრდას, batch სამუშაოს ან რელიზის დროს დროებით დამატებით პროცესებს. ერთიანი „ყოველი შემთხვევისთვის“ პროცენტი პასუხს ვერ გასცემს, როდის ამოიწურება რესურსი. სჯობს ჩაიწეროს, რომელ მაჩვენებელზე დაიგეგმება გადახედვა და რამდენი დრო სჭირდება შემდეგ ნაბიჯს.
საცავის მოცულობას აღდგენის დროც ახლავს
დისკების ნომინალური ჯამი აპლიკაციისთვის ხელმისაწვდომ მოცულობას არ უდრის. მაგალითად, ორი 960 GB დისკის mirror-ში მონაცემებისთვის ნომინალურად 960 GB რჩება, ფაილური სისტემის, OS-ისა და სხვა დანახარჯებამდე. საბოლოო usable სივრცე არჩეულ layout-სა და კონფიგურაციაზე გადაამოწმეთ.
RAID სარეზერვო ასლი არ არის. შემთხვევით წაშლილ ან დაზიანებულ მონაცემს mirror-იც შეიძლება დაექვემდებაროს. backup-ის მდებარეობა, retention და აღდგენის პროცესი ცალკე მოთხოვნებია. snapshot-ის არსებობაც დამოუკიდებელ backup-ს ავტომატურად არ ამტკიცებს.
საცავის შეფასებაში მოცულობასთან ერთად გამოიყენეთ შესაბამისი I/O პროფილი: დიდი ფაილის თანმიმდევრული გადაცემა, მცირე შემთხვევითი ოპერაციები და latency განსხვავებული ამოცანებია. NVMe-ის სახელწოდება კონკრეტული აპლიკაციის response time-ის გარანტია არ არის.
საცავის მაგალითიც ერთეულებით დაწერეთ. პირობითი ორი 960 GB დისკი mirror რეჟიმში ორ დისკზე მოთავსებულ მონაცემის ორ ასლს ქმნის; ეს მომხმარებლისთვის 1920 GB usable სივრცეს არ ნიშნავს. ფაილური სისტემის, ერთეულებისა და რეზერვის შემდეგ ხელმისაწვდომი მოცულობაც ცალკე დასაზუსტებელია. RAID-ისა და backup-ის ერთ სტრიქონში გაერთიანება შედარებას აბუნდოვანებს.
აღდგენაზე საუბრისას ჰკითხეთ საკუთარ თავს, რამდენი ხნის მონაცემის დაკარგვაა მისაღები და რამდენ ხანში უნდა აღდგეს კონკრეტული მომსახურება. შემდეგ გადაამოწმეთ, რეალურად რისი აღდგენის ტესტი გაქვთ: ფაილის, ბაზის თუ მთლიანი აპლიკაციის. ასლის არსებობა და მომსახურების გამართული დაბრუნება ერთი და იგივე შედეგი არ არის. ასლის ადგილი, იზოლაცია და retention ცალკე უნდა დადასტურდეს.
შეთავაზებები ერთსა და იმავე ენაზე შეადარეთ
ორი განსხვავებული ჰიპოთეზური შემთხვევა შეადარეთ: ანგარიშგების სისტემა მცირე concurrency-ით, მაგრამ მძიმე batch გამოთვლებით; მაღაზია ბევრი პარალელური მოთხოვნით და ხშირად განახლებადი მონაცემებით. ერთნაირი დისკის მოცულობა არ ნიშნავს, რომ ორივეს ერთნაირი CPU/RAM/I/O სჭირდება.
| საკითხი | მისაწოდებელი ინფორმაცია |
|---|---|
| აპლიკაცია | Stack, OS, ლიცენზიები და მართვის მოდელი |
| დატვირთვა | ჩვეული/პიკური concurrency, batch სამუშაო |
| RAM | გაზომილი მოხმარება და თავისუფალი რეზერვი |
| საცავი | Usable სივრცე, ზრდა, I/O და RAID მოთხოვნა |
| ქსელი | აუდიტორია, port/traffic, IP და დამოკიდებულებები |
| მდგრადობა | Backup, აღდგენის მიზნები და პასუხისმგებლობა |
სერვერის ფასს ოპერირების ხარჯიც დაუმატეთ
შეთავაზებაში გადაამოწმეთ setup/აქტივაცია, კონტრაქტის ვადა, OS/panel ლიცენზიები, მართვა, backup, IP და ქსელის პირობები. SERVER1-ის მიმდინარე გვერდსა და ინდივიდუალურ შეთავაზებას დაეყრდენით; უცვლელი ფასი ან ყველა კონფიგურაციის მარაგი ნუ ივარაუდებთ.
ოპერირების პასუხისმგებლობა დაწერეთ მოქმედებებით. ვინ განაახლებს OS-ს, ვინ აკვირდება შეტყობინებებს, ვინ შეცვლის აპლიკაციის კონფიგურაციას და ვინ მართავს ინციდენტს? სიტყვა Managed მხოლოდ სათაურია, სანამ კონკრეტული სერვისის scope არ გადაამოწმეთ. ასევე წინასწარ გაარკვიეთ, რომელი ლიცენზია, მესამე მხარის სერვისი ან ერთჯერადი სამუშაო შედის ფასში.
მიღების ეტაპზე არ შემოიფარგლოთ აპარატურის ჩამონათვალის ნახვით. შეადარეთ მოწოდებული კონფიგურაცია შეთანხმებას, შეინახეთ საწყისი დაკვირვება და წარმომადგენლობითი აპლიკაციის შედეგი. გადატანა ცალკე ცვლილებაა: უნდა ჰქონდეს მონაცემის სინქრონიზაციის, დაბრუნებისა და მომხმარებლის რეალური გზის შემოწმების გეგმა. ეს გეგმები ახალი სერვერის მზადყოფნასა და მიგრაციის დასრულებას ერთმანეთისგან გამოყოფს.
brief, რომელიც ტექნიკურ საუბარს დააჩქარებს
ქვემოთ მოცემული ჩანაწერი გასაგები შეკითხვის საწყისია. ყველა ველის შევსება აუცილებელი არ არის: თუ რიცხვი არ იცით, მიუთითეთ „გასაზომია“ და დაწერეთ, საიდან შეიძლება მისი მიღება. გაურკვევლობის ცალსახად დანახვა უკეთეს შეთავაზებას აჩქარებს, ვიდრე ზუსტი გარეგნობის გამოგონილი მოთხოვნა.
დანიშნულება: [აპლიკაცია და მნიშვნელოვანი ოპერაცია]
დაკვირვების პერიოდი: [თარიღები და პიკი]
CPU/RAM/I/O: [გაზომილი მონაცემი ან გასაზომი]
მონაცემი: [მოცულობა, ზრდა, usable სივრცე]
აღდგენა: [მისაღები დანაკარგი და დრო]
მართვა: [პასუხისმგებლები და დასაზუსტებელი scope]
მიღება: [საცდელი სცენარი და გადაწყვეტილების პირობა]ამ brief-ით შეადარეთ Dedicated სერვერების მიმდინარე შეთავაზებები. თუ ოპერირებისთვის დახმარება გჭირდებათ, Managed Dedicated-ის მოთხოვნაში მიუთითეთ კონკრეტული სამუშაოები. კონფიგურაციისა და მომსახურების საზღვრების ერთად დაზუსტება ამცირებს ვარაუდზე გაკეთებულ შესყიდვას.
პირველი დაკვირვების შესაგროვებლად: Linux VPS Monitoring: CPU, RAM, Disk და Load როგორ წავიკითხოთ სწორად.
რესურსის წნევისა და მეხსიერების პარამეტრების ტექნიკური წყაროები: Linux kernel - Pressure Stall Information; PostgreSQL - Resource consumption.
