ჰოსტინგ პროვაიდერის არჩევა: რას უნდა დააკვირდე, შიგნიდან დანახული

ჰოსტს რომ ვარჩევთ, ექვს რამეს ვუყურებთ, ამ თანმიმდევრობით: რა CPU-ზე მოხვდება დატვირთვა რეალურად და რამდენად სწრაფია მისი ერთი ბირთვი, რად იქცევა ყოველი "unlimited" გვერდზე, როცა პირობებს წავიკითხავთ, გვეუბნება თუ არა status page სიმართლეს ცუდ დღეს, ვინ და როგორ დაგიბრუნებს მონაცემებს, მანქანის რა ნაწილამდე მიგწვდება ვინმეს თხოვნის გარეშე და პასუხობს თუ არა ადამიანი, როცა წერ. ფასი ყველაფრის შემდეგ მოდის, რადგან იაფი გეგმა, რომელიც ექვსიდან რომელიმეზე ვარდება, იაფი არ არის.

ჩვენ ვმართავთ RE:NODE პლატფორმას - ორკესტრაციას, რომელიც კლიენტების სერვერებს ქმნის, ზრდის და აღადგენს, game, VDS, web, database და storage ხაზებს და მათ გარშემო მონიტორინგსა და backup-ის ავტომატიზაციას. ამან გვაჩვენა უხერხული ხედი იმაზე, როგორ იყიდება ჰოსტინგი იმასთან შედარებით, როგორ მუშაობს. ქვემოთ უმეტესობა ის არის, რასაც ოპერატორები იციან და გეგმის გვერდი არ ამბობს. ის ეხება ნებისმიერ ჰოსტს, ჩვენ ჩათვლით, და ნაწილი განზრახ არასასიამოვნოა ჩვენნაირი პატარა პროვაიდერებისთვის.

უფრო მოკლე checklist ვერსია არის game server ჰოსტინგის არჩევა-ში. ეს მის უკან მდგარი მსჯელობაა.

რატომ ტყუის spec ცხრილი გამოტოვებით#

გეგმის გვერდი იწერება შესადარებლად, ამიტომ ჩამოთვლის იმას, რაც ადვილად ედრება: გიგაბაიტები RAM-ისა, გიგაბაიტები დისკისა, ბირთვების რაოდენობა, ფასი. არცერთი მათგანი ტყუილი არ არის. პრობლემა ის არის, რაც გამოტოვებულია, და შიგნიდან შეგვიძლია გითხრათ, რომ გამოტოვებები შემთხვევითი არ არის.

RAM-ის გაყიდვა ადვილია და პატიოსნად მიწოდებაც, რადგან მეხსიერება ან არის, ან არა. დისკის ზომაც ასეა. ბირთვებზე ხდება მოლიპული, რადგან "2 vCPU" არაფერს ამბობს იმაზე, რომელი CPU, რამდენად ძველია, რამდენად სწრაფია ერთი thread, ან რამდენი სხვა კლიენტი დგას რიგში იმავე ფიზიკურ ბირთვებზე. bandwidth კიდევ უფრო მოლიპულია. ხოლო ის, რაც გადაწყვეტს, დარჩები თუ არა - backup-ები, წვდომა, support, რა ხდება ღამის სამ საათზე - გეგმის გვერდზე იშვიათად ჩანს საერთოდ.

ამიტომ წესი, რომელზეც შევჩერდით, მარტივია: გვერდზე მოცემული რიცხვები არის იმის მინიმუმი, რაც უნდა იცოდე, და არა პასუხი. ქვემოთ ყველაფერი იმ კითხვებზეა, რომლებზეც ეს რიცხვები პასუხს არ იძლევა.

CPU: თაობა და ერთი thread-ის სიჩქარე ბირთვების რაოდენობაზე მნიშვნელოვანია#

ეს ჰოსტინგში ყველაზე გაუგებარი რამეა და game server-ებისთვის ყველაზე მნიშვნელოვანი.

game server-ების უმეტესობა მნიშვნელოვან საქმეს ერთ thread-ზე აკეთებს. სიმულაციის tick - ობიექტების მოძრაობა, თამაშის ლოგიკა, იმის გადაწყვეტა, რას ხედავს თითოეული მოთამაშე შემდეგ - მთავარ thread-ზე სრულდება, ხოლო დანარჩენი ბირთვები ქსელს, chunk-ების ჩატვირთვას, შენახვას და მსგავსს ეხმარება. Minecraft ცნობილი მაგალითია, მაგრამ პატერნი ფართოა: როცა სერვერი ლაგავს, ჩვეულებრივ ერთი ბირთვია 100%-ზე, სანამ დანარჩენები უქმად დგანან. ამაზე კარგად დავწერეთ წერილში game server CPU-ს გამოყენების წაკითხვა, ხოლო game server-ების CPU მოთხოვნები თამაშ-თამაშად განიხილავს.

რას ნიშნავს ეს ჰოსტის არჩევისას:

• ახალი CPU მაღალი სიხშირით ჩვეულებრივ აჯობებს უფრო ძველ CPU-ს მეტი ბირთვით. ერთ ციკლზე წარმადობა თაობებს შორის ბევრად შეიცვალა, ამიტომ "3.0 GHz" ბევრი წლის წინანდელ CPU-ზე და "3.0 GHz" ახალზე ერთი და იგივე სიჩქარე არ არის.
• ბევრბირთვიანი სერვერული ჩიპები შესანიშნავია ბევრი რამის ერთდროულად გასაშვებად და ხშირად არაფრით გამორჩეული ერთი რამის სწრაფად გასაშვებად. ეს სწორი კომპრომისია ჰოსტისთვის, რომელიც ბევრ ვებ აპლიკაციას ფუთავს. ერთი დატვირთული game server-ისთვის - არასწორი.
• "vCPU" ჩვეულებრივ ერთი აპარატურული thread-ია და არა ერთი ფიზიკური ბირთვი. ორი vCPU შეიძლება ერთი ბირთვის ორი hyperthread იყოს, რაც ორზე ნაკლებია სრული ბირთვისა, როცა ორივე დაკავებულია.

კითხვა, რომელიც ნებისმიერ ჰოსტს უნდა დაუსვა, არის "რომელ CPU მოდელზე მუშაობს ეს გეგმა?" კარგი პასუხი მოდელს ასახელებს. სამართლიანი პასუხი ამბობს "ეს node-ის მიხედვით განსხვავდება, აი მოდელები, რომლებსაც ვიყენებთ". გაუგებარი პასუხი - "საწარმოო დონის პროცესორები" - გეუბნება, რომ მათ ურჩევნიათ, არ იცოდე. ჰოსტების სამართლიანობისთვის, ყველას არ შეუძლია მოდელი დაგიპირდეს, რადგან node-ები იცვლება. მაგრამ შეუძლიათ გითხრან, რა არის ფლოტში დღეს.

RE:NODE-ზე VDS ხაზი თავის CPU-ს ასახელებს (Intel i9-9900K), ხოლო გაზიარებულ ხაზებზე გეგმის CPU მაჩვენებელი არის ერთი ბირთვის პროცენტი, რომელიც მკაცრ ლიმიტადაა აღსრულებული - 250 ნიშნავს 2.5 vCPU შეზღუდულ წილს და არა 2.5 ბირთვს, რომლის გადაჭარბებაც შეგიძლია. ლიმიტზე მდგომი სერვერი ნელია და არასოდეს ჩერდება ამის გამო. გაზიარებული node-ებისთვის მოდელს არ ვაქვეყნებთ, ამიტომ თუ ეს შენთვის მნიშვნელოვანია, ეს კითხვა ჩვენც უნდა დაგვისვა.

როგორ შეამოწმო, რა მიიღე რეალურად

VDS-ზე shell გაქვს, ამიტომ შეხედე:

$ lscpu | grep -E 'Model name|^CPU\(s\)|Thread'$ sysbench cpu --threads=1 --time=30 run$ vmstat 1 10

პირველი ხაზი გეუბნება მოდელს და რამდენი thread გაქვს. ერთი thread-ით sysbench-ის გაშვება გაძლევს events-per-second რიცხვს, რომლის შედარებაც ჰოსტებს შორის შეგიძლია - გაუშვი ყოველ კანდიდატზე ერთნაირად. vmstat-ში უყურე st სვეტს: steal time არის CPU, რომელიც შენმა ვირტუალურმა მანქანამ მოინდომა და hypervisor-მა სხვას მისცა. რამდენიმე პროცენტი ხანდახან ნორმალურია გაზიარებულ აპარატურაზე. steal, რომელიც მაღლა დგას, სანამ შენი დატვირთვა დაბალია, ნიშნავს გადატვირთულ ჰოსტს, და გაზიარებული CPU და ხმაურიანი მეზობლები განმარტავს, რისი გაკეთება შეგიძლია და რისი არა.

game პანელზე ჩვეულებრივ shell არ გაქვს, მაგრამ ჰოსტის /proc/cpuinfo ხშირად ჩანს container-ის შიგნიდან, და კონსოლის CPU გრაფიკი ლიმიტთან შედარებით გეუბნება, შეზღუდული ხარ თუ არა ნაყიდი წილით.

რას ნიშნავს "unlimited"#

ოპერატორის მხრიდან არაფერია შეუზღუდავი. ყოველ რესურსს, რომელთანაც ვმუშაობთ, ფიზიკური ჭერი აქვს: uplink-ის ტევადობა, დისკის გამტარობა, inode-ები, ენერგია. როცა გეგმა ამბობს "unlimited", ეს სამიდან ერთს ნიშნავს და უნდა იცოდე რომელს.

"Unmetered" არის პატიოსანი სიტყვა bandwidth-ისთვის: გიგაბაიტზე არ გიანგარიშებენ. ეს დაპირება არ არის, რომ მთელი თვე გაზიარებულ uplink-ს გაჯერებ. ყველა ჰოსტს unmetered გეგმით აქვს წერტილი, სადაც ვიღაცის ტრაფიკი სხვა კლიენტებს აზიანებს, და ერთადერთი რეალური კითხვა ისაა, გეუბნებიან თუ არა, სად არის ის და რა ხდება, როცა მიაღწევ - throttle, წერილი, შეჩერება. ჩვენი ფორმულირებაა, რომ unmetered ნიშნავს გიგაბაიტზე არ ითვლება და არა გაზიარებული uplink-ის გაჯერების ნებართვას, და bandwidth და fair use განმარტავს, რას ნიშნავს ეს პრაქტიკაში.

game server-ზე "unlimited player slots" ის არის, რაც ყველაზე მეტად გვაღიზიანებს, რადგან ტექნიკურად მართალია და პრაქტიკულად უაზრო. რამდენი მოთამაშე ეტევა, თამაშს, CPU-სა და RAM-ს გადაწყვეტს და არა პანელში რიცხვი. ჰოსტი, რომელიც პატარა გეგმაზე უსასრულო slot-ებს რეკლამობს, ყიდის რიცხვს, რომლის გამოყენებაც არ შეგიძლია.

ტესტი, რომელსაც ვიყენებთ: თუ გეგმა ამბობს unlimited, მომსახურების პირობებში ვეძებთ "fair use", "acceptable use", "excessive" და "inode". რასაც პირობები ამბობს, ის არის რეალური გეგმა. თუ პირობები საერთოდ არაფერს ამბობს, ლიმიტი მაინც არსებობს - უბრალოდ მას ცვლაში მყოფი ვინმე ახორციელებს, განსჯით, გაფრთხილების გარეშე.

როგორ წავიკითხოთ status page#

ახლა ყველა ჰოსტს აქვს status page და უმეტესობა თითქმის ყოველთვის მწვანეა. ეს თავისთავად ძალიან ცოტას ამბობს. ამის ნაცვლად ამას ვუყურებთ.

1. ვინ ზომავს. status page, რომელიც ჰოსტის ქსელის გარედან ავტომატური შემოწმებებით იკვებება, უფრო მეტს ღირს, ვიდრე ისეთი, რომელსაც ვინმე ფაქტის შემდეგ ხელით ასწორებს. ხელით რედაქტირებული გვერდი მწვანეა, სანამ ადამიანი არ გადაწყვეტს, რომ არ უნდა იყოს.
2. რამდენად დეტალურია. ერთი "All systems operational" ბანერი მთელ კომპანიაზე მალავს ფაქტს, რომ შენი node შეიძლება ჩავარდნილი იყოს, სანამ დანარჩენი მუშაობს. node-ზე ან სერვისზე კომპონენტები უფრო პატიოსანია.
3. ისტორია. გადაახვიე უკან. გვერდი წლის განმავლობაში ინციდენტების გარეშე ან საოცრად იღბლიან ოპერაციას აღწერს, ან არ ახლდება. რეალურ ინფრასტრუქტურას ცუდი დღეები აქვს, და პატიოსანი გვერდები მათ აჩვენებენ.
4. რას ამბობს ინციდენტის ჩანაწერები. "ვიძიებთ", რასაც მოსდევს "მოგვარდა" შუაში არაფრით, არაფერს გასწავლის. ჩანაწერები, რომლებიც ამბობენ, რა გაფუჭდა, რა დაზარალდა და რა შეიცვალა შემდეგ, გეუბნება, როგორ ფიქრობს გუნდი.
5. სად არის განთავსებული. თუ status page იმავე ინფრასტრუქტურაზე ცხოვრობს, რასაც აღწერს, ის ზუსტად მაშინ ეცემა, როცა გჭირდება.

uptime პროცენტებზე: ისინი აზრიანია მხოლოდ გაზომვის ინტერვალისა და განსაზღვრების გვერდით. 99.9% 30-დღიან თვეში დაახლოებით 43 წუთის შეფერხებას უშვებს; 99.99% დაახლოებით ოთხს. თუ შემოწმება ხუთ წუთში ერთხელ ეშვება, ამაზე მოკლე შეიძლება არასოდეს დაინახოს. ხოლო SLA ჩვეულებრივ ნიშნავს ნაწილობრივ კრედიტს შენი ანგარიშიდან და არა შენი შეფერხების დაბრუნებას - წაიკითხე, რა არის საშუალება, სანამ რიცხვით აღფრთოვანდები.

რისი ღირსიც არის, RE:NODE-ის status page ხელმისაწვდომობას ყოველ ხუთ წუთში ზომავს და ჩვენ არ ვაქვეყნებთ uptime პროცენტს ან SLA-ს. ჯობია ეს პირდაპირ ვთქვათ, ვიდრე რიცხვი დავბეჭდოთ. ეს ისე უნდა აწონო, როგორც ნებისმიერ ჰოსტზე.

backup-ები და ვინ აღადგენს მათ#

აქ ყველაზე მტკიცე აზრი გვაქვს, რადგან backup-ის ავტომატიზაცია პლატფორმის მართვის დიდი ნაწილია, და რადგან უფსკრული "ვაკეთებთ backup-ებს" და "შენი მონაცემები შეგიძლია დაიბრუნო" შორის არის ადგილი, სადაც ჰოსტინგით იმედგაცრუების უმეტესობა ცხოვრობს.

ჰოსტს "backup-ებში" ორი სხვადასხვა რამის გაგება შეუძლია:

• პლატფორმის backup-ები - ჰოსტი საკუთარ დისკებს აკოპირებს, რომ მანქანა აღადგინოს, თუ აპარატურა გაფუჭდა. ჩვეულებრივ ვერ ხედავ, ვერ ირჩევ, რა შედის და ვერ აღადგენ ერთ ფაილს მათგან თავად. ისინი იცავენ ჰოსტის უნარს, თავიდან ააგოს, და არა შენს უნარს, შეცდომა გააუქმო.
• კლიენტის backup-ები - შენი სერვერის ასლები, რომელთა შექმნა, დაგეგმვა, აღდგენა და ჩამოტვირთვა შეგიძლია.

უნდა იცოდე, რომელს მოიცავს გეგმა, და გინდა მეორე სახეობა. შემდეგ გინდა პასუხები ამ კითხვებზე:

• შემიძლია თავად აღვადგინო, თუ ticket უნდა გავაგზავნო და ველოდო?
• შემიძლია ჩამოვტვირთო, რომ ასლი ამ ჰოსტის გარეთ საერთოდ არსებობდეს?
• სად ინახება? backup იმავე დისკზე, რომელზეც დასაცავი მონაცემებია, კომფორტია და არა backup.
• რა ხდება backup-ებთან, როცა გავაუქმებ ან სერვერს წავშლი?
• აღუდგენია ვინმეს ბოლო დროს რომელიმე?

ეს ბოლო ყველაზე მნიშვნელოვანია. როგორც ჩვენი ფრაზა ამბობს, backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. ძლიერი შეხედულებები გვაქვს აღდგენის ტესტირებაზე სანამ დაგჭირდება, და ისინი არის აღდგენის ტესტი სანამ საჭირო გახდება-სა და backup-ები, რომლებიც მართლა აღდგება-ში.

RE:NODE-ზე ყველა გეგმას აქვს backup slot-ები: მოთხოვნით ან გრაფიკით, აღდგენა ღილაკით, ჩამოტვირთვადი, rotation-ისგან დასაბლოკი და იმ მანქანის გარეთ შენახული, რომელსაც იცავს. სერვერის წაშლა შლის მის backup-ებს, დაბლოკილებიც ჩათვლით - ზუსტად ისეთი დეტალი, რომელსაც ნებისმიერ ჰოსტზე უნდა ეძებო, რადგან ხალხი მას არასწორი გზით სწავლობს. ცალკე, პლატფორმა იღებს ღამის backup-ებს, დამოუკიდებელ აპარატურაზე კოპირებულს. არცერთი არ ცვლის ასლს, რომელსაც თავად ინახავ, და ამას ნებისმიერი ჰოსტის backup-ებზე ვიტყოდით, RE:NODE-ისაც ჩათვლით.

პანელი, ფაილები და console-ზე წვდომა#

აქ კითხვაა, შენი სერვერის რა ნაწილამდე მიგწვდება ვინმესთვის თხოვნის გარეშე. რაც ნაკლებზე მიგწვდება, მით უფრო ყოველი პატარა პრობლემა support ticket ხდება და მით უფრო ძნელია წასვლა.

პანელზე მომუშავე game server-ისა ან app ჰოსტისთვის მინიმუმი, რასაც მივიღებდით:

• ცოცხალი console ნედლი, გაუფილტრავი გამოტანით და ბრძანების ხაზით. თუ ჰოსტი მხოლოდ გაწმენდილ log-ს ან "server is running" ნიშანს გაჩვენებს, თავად ვერაფერს დიაგნოსტიკებ.
• ფაილების მენეჯერი და SFTP. ფაილების მენეჯერი სწრაფი რედაქტირებისთვისაა; SFTP არის გზა, რომლითაც მთელ სამყაროს, modpack-ს ან საიტს შიგნით-გარეთ გადაიტან. SFTP-ის არარსებობა თავისთავად საფრთხის ნიშანია.
• გაშვების ბრძანება ან ყოველ შემთხვევაში მისი ცვლადები. საბოლოოდ დაგჭირდება გაშვების flag, JVM პარამეტრი ან სხვა branch.
• რესურსების გრაფიკები ლიმიტებთან შედარებით, რომ ნახო, CPU წილს ან მეხსიერების ჭერს ხვდები თუ არა.
• კონტროლი იმაზე, ვის აქვს წვდომა, "ყველაფერზე" ვიწრო უფლებებით.

VDS-ისთვის მინიმუმია root, თავიდან დაყენების გზა და რაიმე out-of-band console (VNC ან serial) ისეთი დროისთვის, როცა firewall-ის წესით თავს გამოიკეტავ. ჰკითხე, რას მიიღებ, თუ SSH პასუხს შეწყვეტს. "გახსენი ticket" სუსტი პასუხია.

აქ დამალული გასვლის კითხვაც არის. შეგიძლია თუ არა შენი მონაცემები ნორმალური ფორმატით გამოიტანო ჰოსტის დახმარების გარეშე? თუ პასუხი დიახ, ცუდი ჰოსტი შაბათ-კვირას გიჯდება. თუ არა, იმას, რასაც ისინი გადაწყვეტენ.

რას აძლევს RE:NODE პანელი ყველა გეგმას დონეების გარეშე: გაუფილტრავი ცოცხალი console ბრძანების ხაზით, ფაილების მენეჯერი, SFTP თითო სერვერის credentials-ით და არა თითო ანგარიშის, Startup ტაბი game და გარემოს ცვლადებისთვის, CPU, მეხსიერებისა და დისკის გრაფიკები ლიმიტებთან და subuser-ები დეტალური უფლებებით. ის აგებულია Pterodactyl-სა და Wings-ზე ჩვენი პანელით მათ ზემოთ, ამიტომ თუ Pterodactyl იცი, ფორმა ნაცნობი იქნება - რა არის Pterodactyl ამას განმარტავს.

support, რომელსაც მიაღწევ#

რისი გაგებაც გეგმის გვერდიდან არავის შეუძლია, support-ის ხარისხია, და ეს არის რაც წყვეტს, დარჩები თუ არა. ჰოსტინგი support ბიზნესია სერვერებით დამატებული.

რას ვეძებთ:

• ერთზე მეტი არხი და მინიმუმ ერთი, რომელიც წერილობით კვალს ტოვებს. ticket სისტემა, სადაც მიმაგრებული ფაილები პირადია, უკეთესია საჯარო Discord არხზე ყველაფერზე, რაც credentials-ს ან log-ებს ეხება.
• ნათელი განცხადება, როდის არიან ადამიანები რეალურად ადგილზე. პატარა ჰოსტისგან "24/7 support" ხშირად ნიშნავს "ვიღაცას შეტყობინება მოუვა". ეს არ არის არაკეთილსინდისიერი, მაგრამ არ არის იგივე, რაც ცვლაში მყოფი ადამიანი. ჯობია ჰოსტმა თავისი რეალური საათები გითხრას.
• პასუხები, დაწერილი ვინმეს მიერ, ვინც კითხვა წაიკითხა. ცოდნის ბაზის ბმულის ჩასმა კონკრეტულ კითხვაზე პასუხად გუნდის ნიშანია, რომელიც საკვანძო სიტყვებით ახარისხებს.
• შეუძლია თუ არა support-ს რაღაცის გაკეთება და არა მხოლოდ გადაცემა. შეუძლია პასუხის გამცემ ადამიანს backup-ის აღდგენა, port-ის გახსნა, სერვერის გადატანა? თუ შიდა ticket-ს ხსნის და ინჟინერს ელოდება?

აი არასასიამოვნო რამ ოპერატორის მხრიდან: პატარა ჰოსტები ხშირად უკეთესები არიან support-ში, ვიდრე დიდები, რადგან პასუხის გამცემმა ხშირად კოდი დაწერა, და უარესები გადაფარვაში, რადგან ნაკლებნი არიან. დიდი ჰოსტები საპირისპიროა. გადაწყვიტე, რა გჭირდება. ჰობი სერვერს დილამდე შეუძლია დაელოდოს; ფასიან community-ს ან ბიზნეს აპლიკაციას შესაძლოა არა.

RE:NODE support არის ticket პანელიდან (ის აღწევს მთელ staff-ს, პირადი მიმაგრებებით), Discord და ელფოსტა. მთელი დღე-ღამის staff-ზე არ ვრეკლამობთ, და ჩვენი ზომის ჰოსტს, რომელიც ამას აკეთებს, არ ვენდობოდით.

ჰოსტის ტესტირება პირველ კვირაში#

პირველ კვირაში ჰოსტზე უფრო მეტს გაიგებ, ვიდრე მიმოხილვების კითხვით. პირველი გადახდა მიიჩნიე ტესტის ფასად და ტესტი მიზანმიმართულად ჩაატარე. სადაც ჰოსტი მოკლე ვადას გვთავაზობს, აიღე.

მარშრუტის ტესტი პირველია, რადგან CPU-ს არავითარი რაოდენობა ცუდ გზას მანქანასა და შენს მოთამაშეებს შორის ვერ გამოასწორებს. გაუშვი იქიდან, სადაც შენი მოთამაშეები რეალურად არიან და არა იქიდან, სადაც შენ ხარ:

$ mtr -rwc 100 203.0.113.10$ fio --name=rand --rw=randread --bs=4k --size=1G --iodepth=32 \    --ioengine=libaio --direct=1 --runtime=30 --time_based

იქ მისამართი დოკუმენტაციის მაგალითია - ჩასვი შენი სერვერის. traceroute-ისა და mtr-ის წაკითხვა განმარტავს, როგორ წაიკითხო გამოტანა და ყველაზე გავრცელებულ არასწორ წაკითხვას: დანაკარგი შუა hop-ზე, რომელიც ბოლო hop-მდე არ გრძელდება, ჩვეულებრივ რაუტერია, რომელიც probe-ებს დაბალ პრიორიტეტს აძლევს, და არა რეალური დანაკარგი.

შემდეგ დატვირთე სერვერი ისე, როგორც გამოიყენებ, იმ საათებში, როცა გამოიყენებ. მანქანა, რომელიც სამშაბათს დილის 10 საათზე კარგად გადის benchmark-ს და შაბათ საღამოს ბარბაცებს, სიმძლავრის პრობლემა აქვს, რომელსაც ერთი benchmark არ აჩვენებს. გაიმეორე ერთი thread-ით sysbench რამდენიმე სხვადასხვა დროს და შეადარე.

დაუსვი support-ს ერთი რეალური კითხვა, რომლის პასუხიც უკვე იცი, და აღნიშნე, რამდენ ხანში პასუხობენ და სწორია თუ არა. აიღე backup, წაშალე ფაილი, რომლის გარეშეც იცხოვრებ, აღადგინე, ჩამოტვირთე არქივი და გახსენი შენს მანქანაზე. გამოიტანე შენი მონაცემები ისე, როგორც წასვლისას გამოიტანდი. თუ ამათგან რომელიმე ძნელია პირველ კვირაში, მეექვსე თვეში უარესი იქნება.

საფრთხის ნიშნები#

ზოგი მათგანი გარიგების გამრღვევია; ზოგი უბრალოდ მიზეზია, უფრო მკაცრად იკითხო. შევეცადეთ ჩამოგვეთვალა მხოლოდ ის, რასაც საკუთარ პლატფორმასაც მოვთხოვდით.

• არსად არ ჩანს CPU მოდელი და გაურბიან, როცა ჰკითხავ.
• "Unlimited" ყველაფერი, fair-use განყოფილების გარეშე, რომელსაც იპოვი.
• status page, რომელსაც ინციდენტი არასოდეს უჩვენებია.
• DDoS დაცვის განცხადება დიდი რიცხვით და ახსნის გარეშე, რა ფილტრდება. რეალური დაცვა აშკარა მოცულობით წყალდიდობას აგდებს; შეტევები, რომლებიც რეალურ მოთამაშეებს ჰგავს, ბევრად უფრო ძნელია, და ვინც ყველაფრის შეჩერებას გპირდება, გყიდის წინადადებას და არა სერვისს. მეტი ამაზე - DDoS შეტევები game server-ებზე.
• SFTP-ის გარეშე, ნედლი console-ის გარეშე, ან backup-ები, რომლებიც მხოლოდ ticket-ით აღდგება.
• მონაცემების ექსპორტის გზა არ არსებობს, ან ექსპორტი გაუქმების უკანაა დამალული.
• სამუდამო გეგმები, ან ფასები, რომლებიც ყველა სხვაზე იმდენად დაბალია, რომ არითმეტიკა არ ადგება. აპარატურა, ენერგია და bandwidth ყველასთვის ერთნაირად ღირს მოცემულ ბაზარზე; ამაზე დაბალი ფასი რაღაცით სუბსიდირებულია - ზედმეტი გაყიდვით, მოკლე სიცოცხლით, ან ორივეთი.
• პირობები, რომლებიც ჰოსტს საშუალებას აძლევს, შეგაჩეროს იმ რესურსების გამოყენებისთვის, რისთვისაც გადაიხადე. შენი CPU წილის 100%-ზე მუშაობამ სერვერი ნელი უნდა გახადოს და არა მოაშოროს.
• ზეწოლა, მიიღო გრძელი ვადა წინასწარ, სანამ რამეს გამოსცდიდი.

არცერთი ამათგანი იმის დასტური არ არის, რომ ჰოსტი ცუდია. რამდენიმე ერთად ჩვეულებრივ დასტურია.

კომპრომისები, რომლებსაც ისევ გავაკეთებდით#

რამდენიმე შეხედულება, პირდაპირ ნათქვამი, ერთ ასეთს რომ ვმართავთ, იქიდან.

ავიღებდით ჰოსტს, რომელიც თავის საზღვრებს აღიარებს, იმას, რომელიც მალავს. ყველა ჰოსტს აქვს bandwidth-ის ჭერი, support-ის გრაფიკი ხვრელებით, მდებარეობა, რომელიც ზოგ მოთამაშეს ერგება და ზოგს არა. ვინც ამას წერს, იმათთან შეგიძლია გეგმავდე. RE:NODE მუშაობს ერთ ლოკაციაზე, გერმანიაში, აპარატურაზე, რომელსაც ჩვენ ვმართავთ - ეს სწორი პასუხია ევროპის მოთამაშეებისთვის და არასწორი შორეულებისთვის, და ჯობია გცოდნოდა გადახდამდე.

ავიღებდით ნაკლებ ფუნქციას და მეტ წვდომას. პანელი პატიოსანი console-ით, SFTP-ით და რეალური backup-ებით სჯობს ისეთს, სადაც ასი ერთი დაწკაპუნების ღილაკია და shell არ არის.

ყოველთვის შევინახავდით საკუთარ ასლს ყველაფრისა, რაც მნიშვნელოვანია, სხვის ინფრასტრუქტურაზე. არა იმიტომ, რომ ჰოსტები დაუდევრები არიან, არამედ იმიტომ, რომ ჩავარდნა, რომლისგანაც იცავ თავს, შეიძლება თავად ჰოსტი იყოს - billing შეცდომა, დახურული ანგარიში, კომპანია, რომელიც მუშაობას წყვეტს.

და გავტესტავდით ვალდებულებამდე. ყველა ჰოსტი, ჩვენც ჩათვლით, საკუთარ ვებგვერდზე უკეთ გამოიყურება, ვიდრე ღამის სამ საათზე. პირველი კვირა არის ადგილი, სადაც ხვდები, რომელი ჰოსტებია ერთნაირი.

თუ უფრო ფართო სურათი გინდა იმაზე, რა სერვერი იქირაო საერთოდ, VPS vs VDS vs dedicated server დასაწყებად კარგი ადგილია.

FAQ#

ყოველთვის უკეთესია თუ არა მეტი ბირთვი game server-ისთვის?

არა. game server-ების უმეტესობას ზღუდავს ერთი ბირთვის სიჩქარე, რადგან მთავარი სიმულაციის ციკლი ერთ thread-ზე მუშაობს. გეგმა ნაკლები ბირთვით ახალ, უფრო მაღალსიხშირულ CPU-ზე ჩვეულებრივ უკეთ გაუშვებს დატვირთულ game server-ს, ვიდრე მეტი ბირთვი უფრო ძველ ან ბევრბირთვიან ჩიპზე. დამატებითი ბირთვები ეხმარება mod-ებს, plugin-ებს, chunk-ების გენერაციასა და რამდენიმე სერვერის გვერდიგვერდ გაშვებას.

რა განსხვავებაა unmetered და unlimited bandwidth-ს შორის?

Unmetered ნიშნავს, რომ გადაცემულ გიგაბაიტზე არ გიანგარიშებენ. Unlimited იგივეს მარკეტინგული სიტყვაა და არასოდეს უნდა წაიკითხო როგორც ჭერის არარსებობა - ყველა ჰოსტს აქვს გაზიარებული uplink და fair-use წერტილი. სასარგებლო კითხვაა, რას აკეთებს ჰოსტი, როცა მიაღწევ: throttle, გაფრთხილება თუ შეჩერება.

უნდა ვენდო თუ არა 99.9% uptime გარანტიას?

მიიჩნიე როგორც განცხადება კომპენსაციაზე და არა საიმედოობაზე. ის 30-დღიან თვეში დაახლოებით 43 წუთის შეფერხებას უშვებს, გაზომვის ინტერვალი წყვეტს, რა ითვლება, და საშუალება ჩვეულებრივ ნაწილობრივი კრედიტია. status page რეალური ინციდენტების ისტორიით უფრო მეტს გეუბნება იმაზე, როგორ მუშაობს ჰოსტი, ვიდრე პროცენტი.

საკმარისია თუ არა მხოლოდ ჰოსტის backup-ები?

ისინი კარგი პირველი ხაზია და არა უფრო მეტი. დარწმუნდი, რომ შეგიძლია თავად აღადგინო და ჩამოტვირთო, და შეინახე მინიმუმ ერთი ახალი ასლი სადმე სრულიად სხვაგან - შენს მანქანაზე ან ცალკე object storage-ზე. თუ პრობლემა თავად ჰოსტის ანგარიშშია, ამავე ჰოსტთან შენახული backup-ები არ დაგეხმარება.

რამდენი ხანი უნდა გავტესტო ახალი ჰოსტი ვალდებულებამდე?

ნორმალური გამოყენების ერთი კვირა, შენი ყველაზე დატვირთული საათების ჩათვლით, საკმარისია პრობლემების უმეტესობის საპოვნელად: მარშრუტის ხარისხი, CPU კონკურენცია პიკზე, support-ის პასუხი და მუშაობს თუ არა აღდგენა და ექსპორტი. გრძელი ვადის გადახდას მოერიდე, სანამ ეს კვირა არ დასრულდება, თუნდაც თვეში უფრო იაფი იყოს.

პატარა ჰოსტი უფრო რისკიანია, ვიდრე დიდი?

განსხვავებულად რისკიანია. პატარა ჰოსტს უფრო მეტი შანსი აქვს, ჰყავდეს support სისტემის ავტორი ადამიანებისგან, და ნაკლები შანსი აქვს, რომ ყოველ საათზე ცვლაში ადამიანი ჰყავდეს. დიდ ჰოსტს მეტი გადაფარვა აქვს და მეტი ფენა შენსა და ინჟინერს შორის. შენი საკუთარი backup-ები და მონაცემების გამოტანის მარტივი გზა ორივე არჩევანს ბევრად უფრო უსაფრთხოს ხდის.