რამდენიმე გეიმ სერვერი ერთ VDS-ზე: პორტები, მომხმარებლები, systemd

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

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

გულახდილად ჰკითხე საკუთარ თავს, ღირს თუ არა#

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

მართვადი გეიმ გეგმა სერვერს გადახდის დადასტურებიდან დაახლოებით ერთ წუთში გაძლევს: ინსტალაცია გაკეთებული, პორტები გამოყოფილი, კონსოლი, ფაილების მენეჯერი, SFTP, დაგეგმილი ამოცანები და backup-ის სლოტები. VDS გაძლევს ცარიელ Debian მანქანას და root პაროლს ერთი დღის განმავლობაში. ამ პოსტის დანარჩენი ყველაფერი სწორედ ამ ორ წინადადებას შორის მანძილია, და პირველად ეს დაახლოებით ერთი შაბათ-კვირაა.

გულწრფელი გამყოფი ხაზი რაოდენობა კი არა, მეხსიერების ფორმაა. ხუთი სერვერი, თითო 2 GB და კვირის უმეტესობას უსაქმო, მშვენივრად იყრის თავს 16 GB VDS-ზე, რადგან ის, რომელსაც პიკი აქვს, მეხსიერებას ოთხისგან სესხულობს, რომლებიც მშვიდადაა. ორი სერვერი, თითო ნამდვილად 6 GB და დატვირთული, საერთოდ ვერ ერთიანდება, და ტყუილად იყიდე სისადმინო სამუშაო. VDS-სა და გეიმ პანელს შორის არჩევანი სრულ არითმეტიკას შეიცავს, იმის ჩათვლით, რა უჯდება შენ თვით ოპერაციულ სისტემას, სანამ რამეს გაუშვებ.

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

ზომა: რა ეტევა რეალურად#

ორი რიცხვი გზღუდავს, და ხშირად ის არ არის, რომელსაც ხალხი ამოწმებს.

მეხსიერება ადვილია. გამოაკელი 300-400 MB მინიმალურ Debian-ს ან Ubuntu-ს, სადაც არაფერია დაყენებული, მეტი - თუ Docker-ს, ვებ სერვერს ან მონიტორინგს დაამატებ, და დარჩენილი გაანაწილე. 8 GB VDS რეალურად დაახლოებით 7 GB-ს გაძლევს გეიმ სერვერებისთვის.

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

დაგეგმე პიკისთვის და არა საშუალოსთვის. ხუთი სერვერი, რომელთაგან თითო უსაქმოდ 800 MB-ს იკავებს და პიკზე 3 GB-ს, პარასკევ საღამოს ერთად ვერ გადარჩება 16 GB-ზე, და მეხსიერების ამოწურვის გამო მოკვლა ჩამოაგდებს იმას, რომელიც იმ მომენტში ყველაზე დიდი იყო და არა იმას, რომელმაც პრობლემა შექმნა. Swap და OOM killer განმარტავს, როგორ მიიღება ეს გადაწყვეტილება და როგორ შეიძლება მასზე გავლენის მოხდენა.

პორტების რუკა, ჯერ ჩაწერილი#

გააკეთე ეს რაიმეს დაყენებამდე. ახლა ხუთი წუთი გიშველის ნაშუადღევს, რომელსაც სერვერზე დახარჯავ, რომელიც ჩაირთვება, არაფერს დაიკავებს და ჩაწერს "address already in use" ხაზს, რომელსაც ერთი საათი ვერ შეამჩნევ.

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

Source-ის ძრავზე თამაშები რთული შემთხვევაა. ერთ მანქანაზე ორ ინსტანციას სჭირდება განსხვავებული მნიშვნელობები -port-ისთვის, +tv_port-ისთვის და +clientport-ისთვის, და მხოლოდ პირველის დაყენება გაძლევს ორ სერვერს, რომლებიც ერთ GOTV სოკეტს ეცილებიან, რაც ისე ვარდება, რომ ლოგი ცუდად აღწერს. გეიმ სერვერის პორტები ახსნილი განმარტავს, რატომ არსებობს query პორტები და რა ხდება, როცა წყვილიდან მხოლოდ ერთია ხელმისაწვდომი.

შემდეგ გახსენი ზუსტად ეს პორტები და სხვა არაფერი:

$ ufw default deny incoming$ ufw allow 22/tcp$ ufw allow 25565/tcp          # Minecraft$ ufw allow 2456:2457/udp      # Valheim game and query$ ufw allow 8211/udp           # Palworld$ ufw enable$ ufw status numbered

RCON პორტები გამონაკლისია: ინტერნეტისთვის ნუ გახსნი. მიაბი RCON 127.0.0.1-ს და მიაღწიე მას SSH გვირაბით, რაც არაფერი ღირს და პრობლემების მთელ კატეგორიას აქრობს. RCON უსაფრთხოდ განმარტავს, რატომ არის ღია RCON პორტი გამოსაცნობი პაროლით სერვერის დაკარგვის უსწრაფესი გზა, ხოლო ufw firewall-ის სახელმძღვანელო დანარჩენ წესებს ფარავს.

ერთი მომხმარებელი თითო სერვერზე#

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

$ adduser --disabled-password --gecos "" --home /srv/valheim valheim$ adduser --disabled-password --gecos "" --home /srv/minecraft minecraft$ chown -R valheim:valheim /srv/valheim$ sudo -u valheim -i           # become that user to install or edit

მიზეზი შეზღუდვაა. გეიმ სერვერები უშვებენ უცნობების დაწერილ მოდებსა და plugin-ებს, ზოგჯერ ტვირთავენ მოთამაშეების ატვირთულ კონტენტს და ხსნიან ქსელურ სერვისებს, რომლებიც არასანდო შეყვანას ამუშავებენ. როცა ერთი მათგანი კომპრომეტირდება - და მოდიფიცირებული სერვერის სისუფთავეში შენახვა ამ შიშის სრული ვერსიაა - დაზარალებული არე ერთი დირექტორია უნდა იყოს და არა მთელი მანქანა. ცალკე მომხმარებელი ასევე ნიშნავს, რომ შემთხვევით არასწორ ტერმინალში გაშვებული rm -rf წარმატების ნაცვლად უფლების შეცდომით ჩავარდება.

პრაქტიკული სარგებელიც არსებობს. ps aux და systemd-cgtop იკითხება, რადგან მომხმარებლის სვეტი მაშინვე გეუბნება, რომელი სერვერი ჭამს CPU-ს. ცალკე Steam ინსტალაციები ცალკე home-ებში მოხვდება, ამიტომ steamcmd +force_install_dir /srv/valheim/server და +force_install_dir /srv/pz/server არასოდეს ეჯახება ერთმანეთს. SteamCMD ახსნილი შეიცავს განახლების სკრიპტის ნიმუშს.

systemd არის ზედამხედველი#

არა tmux, არა screen, არა nohup. ტერმინალის მულტიპლექსერში გაშვებული პროცესი ჩატვირთვისას არ ჩაირთვება, ავარიის შემდეგ არ გადაიტვირთება და უხილავია ყველაფრისთვის, რასაც მოგვიანებით დააყენებ. გამოიყენე systemd unit და გამოიყენე შაბლონი, რომ მეხუთე სერვერის დამატება ერთი გარემოს ფაილის კოპირება იყოს და არა ერთი unit ფაილისა.

[Unit]Description=Game server: %iAfter=network-online.targetWants=network-online.target[Service]User=%iGroup=%iWorkingDirectory=/srv/%iEnvironmentFile=/etc/gameservers/%i.envExecStart=/srv/%i/start.shRestart=on-failureRestartSec=20KillSignal=SIGINTTimeoutStopSec=120CPUQuota=150%MemoryHigh=3500MMemoryMax=4GNice=-5[Install]WantedBy=multi-user.target

%i არის ინსტანციის სახელი, ამიტომ systemctl enable --now gameserver@valheim უშვებს /srv/valheim/start.sh-ს valheim მომხმარებლით და ტვირთავს /etc/gameservers/valheim.env-ს. ერთი unit ფაილი, ერთი ხაზი თითო სერვერზე.

აქ ოთხი დირექტივა ასრულებს რეალურ საქმეს:

• KillSignal=SIGINT ის არის, რომელსაც ხალხი გამოტოვებს და რომელიც სამყაროებს უჯდება. ბევრი გეიმ სერვერი სუფთა შეწყვეტისას ინახავს და SIGKILL-ზე კარგავს ყველაფერს ბოლო ავტოშენახვის შემდეგ. ნაგულისხმევი unit აგზავნის SIGTERM-ს და 90 წამის შემდეგ თმობს; TimeoutStopSec=120 დიდ სამყაროს ჩაწერის დასრულების დროს აძლევს.
• CPUQuota=150% ამ სერვერს ერთ ნახევარ ბირთვზე ზღუდავს. ეს არის პარამეტრი, რომელიც ხელს უშლის ერთ მოდიფიცირებულ სამყაროს, რეიდის დროს დანარჩენი ოთხი შიმშილით ამოწყვიტოს, და მთავარი მიზეზია, რატომ ვამჯობინოთ systemd LinuxGSM-ის საკუთარ ზედამხედველობას.
• MemoryMax სერვერს საკუთარ ჭერს აძლევს. მასზე მიღწევა კლავს მხოლოდ იმ cgroup-ს და არა მანქანაზე ყველაზე დიდ პროცესს, რაც გაცილებით უკეთესი ავარიაა, ვიდრე გლობალური მეხსიერების ამოწურვის მოკვლა.
• Restart=on-failure ხუთმეტი ან ოცი წამის RestartSec-ით. ნუ გამოიყენებ always-ს ერთწამიანი დაყოვნებით: სერვერი, რომელიც ვერ ირთვება, უსასრულოდ ციკლში ტრიალებს და შენს დისკს ლოგებით ავსებს.

შემდეგ შეამოწმე, რას იყენებს ყველაფერი სინამდვილეში:

$ systemctl status gameserver@valheim$ journalctl -u gameserver@valheim -f$ systemd-cgtop$ systemctl list-units 'gameserver@*'

systemd-cgtop არის top-ის თითო სერვისის ვერსია, და ხუთი სერვერის მქონე მანქანაზე ეს უსწრაფესი გზაა იმის სანახავად, რომელს მოუვიდა რამე. unit ფაილის სინტაქსის დანარჩენი ნაწილი systemd სერვისები შენი აპლიკაციებისთვის პოსტშია.

ბრძანებების გაგზავნა პანელის გარეშე#

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

ორი მუშა პასუხია. სადაც თამაში RCON-ს უჭერს მხარს, გამოიყენე ის, localhost-ზე მიბმული:

$ mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASS" "say Restart in 5 minutes" "save-all"$ ssh -L 25575:127.0.0.1:25575 deploy@203.0.113.10   # tunnel from your laptop

სადაც არა, გაუშვი სერვერი მისი მომხმარებლის კუთვნილ tmux სესიაში და მართე send-keys-ით:

$ sudo -u valheim tmux send-keys -t valheim "save" Enter$ sudo -u valheim tmux attach -t valheim      # detach again with Ctrl-b d

ასე იქცევა LinuxGSM და ეს მუშაობს, ოღონდ ოდნავ უცნაური systemd unit-ის ფასად. რომელიც არ უნდა აირჩიო, დაასკრიპტე ის, რასაც ხშირად აკეთებ - გამოცხადება, შენახვა, გაჩერება - რადგან მათი ხელით გაკეთება ხუთ სერვერზე განახლების დროს ისაა, როგორ ვარდება ნაბიჯები.

LinuxGSM: რას გაძლევს და სად წყდება#

LinuxGSM არის shell სკრიპტების ნაკრები, რომელიც ასობით თამაშის dedicated სერვერს აყენებს, აკონფიგურირებს, ანახლებს, backup-ს უკეთებს და აკვირდება. ის ნამდვილად კარგია, უფასოა და შერეული სტეკისთვის საათებს გიფენს თითოეული თამაშის ინსტალაციის შენიშვნების კითხვაზე.

$ wget -O linuxgsm.sh https://linuxgsm.sh && chmod +x linuxgsm.sh$ bash linuxgsm.sh vhserver          # creates the vhserver script$ ./vhserver install$ ./vhserver start$ ./vhserver details                 # ports, paths, status$ ./vhserver update$ ./vhserver backup$ ./vhserver console

თითოეულ თამაშს მოკლე კოდი აქვს - vhserver Valheim-ისთვის, mcserver Minecraft-ისთვის, gmodserver Garry's Mod-ისთვის, tf2server Team Fortress 2-ისთვის და ასე შემდეგ. პარამეტრები ცხოვრობს lgsm/config-lgsm/<code>/<code>.cfg-ში, რომელიც გადაფარავს მოწოდებულ ნაგულისხმევს ისევე, როგორც jail.local აკეთებს fail2ban-ისთვის.

LinuxGSM root-ით გაშვებაზე უარს ამბობს, რაც შენს მაგივრად აღასრულებს ერთი მომხმარებელი თითო სერვერზე წესს. მისი details ბრძანება ბეჭდავს ზუსტ პორტებს, რომლებიც თამაშს სჭირდება, და ეს ზემოთ აღწერილი პორტების რუკის ასაგებად უსწრაფესი გზაა.

ორი გულწრფელი შეზღუდვა. პირველი, მისი monitor ბრძანება cron-იდან გაშვებისთვისაა გათვლილი ყოველ რამდენიმე წუთში და სიამოვნებით გადატვირთავს სერვერს, რომელსაც systemd-იც ცდილობს გადატვირთოს. აირჩიე ერთი ზედამხედველი: ან systemd unit-ები Restart=on-failure-ით და monitor cron ჩანაწერის გარეშე, ან LinuxGSM-ის საკუთარი მონიტორინგი და systemd unit-ის გარეშე. ორივეს გაშვება გაძლევს სერვერს, რომელიც ორჯერ იტვირთება, და ლოგს, რომელსაც აზრი არ აქვს.

*/5 * * * * /srv/valheim/vhserver monitor > /dev/null 2>&10 4 * * * /srv/valheim/vhserver update > /dev/null 2>&1

მეორე, LinuxGSM რესურსების ლიმიტებს არ გაძლევს. ის პროცესს უშვებს; მის CPU-სა და მეხსიერებას არ ზღუდავს. ერთი-ორი სერვერის მქონე მანქანაზე ეს კარგია. ხუთის მქონეზე ზემოთ მოყვანილი CPUQuota და MemoryMax ხაზები განსხვავებაა ერთ ცუდ სერვერსა და ხუთ ცუდ სერვერს შორის, ამიტომ უმეტესობა მაინც systemd unit-ებით მთავრდება და LinuxGSM-ს მხოლოდ ინსტალაციისა და განახლებებისთვის იყენებს. Cron გამოსახულებები ახსნილი გრაფიკის სინტაქსს ფარავს, თუ ხუთი ველი უცნობია.

განახლებები, backup-ები და restart-ები, ეტაპობრივად#

ხუთი სერვერი, რომელიც ერთსა და იმავეს ერთდროულად აკეთებს, შეცდომაა, რომელიც მუშა მანქანას ყოველ ღამე ათი წუთით გამოუსადეგარს ხდის.

• გადაანაწილე backup-ები. 40 GB სამყაროს tar არის უწყვეტი კითხვა და უწყვეტი ჩაწერა ერთსა და იმავე მოწყობილობაზე. ხუთი ერთდროულად მას გაჯერებს. დააშორე ოცი წუთით.
• გადაანაწილე restart-ები. ყველაფრის 05:00-ზე გადატვირთვა ნიშნავს, რომ ყველა სერვერი თავის სამყაროს ერთდროულად ტვირთავს, რაც ყველაზე მძიმეა, რასაც ისინი აკეთებენ. Restart გრაფიკები, რომლებიც გვეხმარება განმარტავს, რომელ სერვერებს სარგებლობა მოაქვს restart-ისგან საერთოდ, რადგან რამდენიმეს არ მოაქვს.
• მოდიფიცირებულ სერვერს ავტომატურ განახლებას ნუ უკეთებ. თამაშის პატჩი გამოსვლის დღესვე არღვევს ყველა მოდს, სანამ ავტორები არ დაეწევიან. ვანილის სერვერები ავტომატურად განაახლე; მოდიფიცირებული - ხელით, შემოწმების შემდეგ, და შეინახე მუშა მოდების საქაღალდის ასლი. რა უნდა გააკეთო, როცა მოდის განახლება ტეხავს აღდგენის პროცედურაა.

systemd timer ამისთვის cron-ზე მოწესრიგებულია, რადგან ლოგი journal-ში ხვდება იმ სერვისის გვერდით, რომლის backup-საც აკეთებ:

$ tar -czf /srv/backups/valheim-$(date +%F-%H%M).tar.gz -C /srv/valheim worlds_local$ find /srv/backups -name 'valheim-*.tar.gz' -mtime +14 -delete$ restic -r sftp:backup@198.51.100.5:/srv/restic backup /srv/valheim/worlds_local

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

და ბოლოს, თვით მანქანა. ყოველკვირეული apt update && apt full-upgrade, ჩართული ავტომატური უსაფრთხოების განახლებები, ნაგულისხმევად ყველაფრის უარმყოფელი firewall, მხოლოდ გასაღებით SSH და fail2ban SSH პორტზე. არაფერი აქედან თავისით არ ხდება, და მანქანა, რომელზეც ხუთი გეიმ სერვერი მუშაობს, უფრო საინტერესო სამიზნეა, ვიდრე ერთის მქონე. პირველი საათი ახალ VDS-ზე ჩამონათვალია, ხოლო Linux ბრძანებები სერვერის ადმინებისთვის ყოველდღიურ კითხვას ფარავს.

ან პანელი დააყენე საკუთარ VDS-ზე#

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

ის ორი კომპონენტია. პანელი არის Laravel აპლიკაცია, რომელსაც სჭირდება ვებ სერვერი, PHP თავისი გაფართოებებით, MySQL-თან თავსებადი მონაცემთა ბაზა, Redis და Composer. Wings არის Go daemon, რომელსაც Docker სჭირდება და პანელთან თავის პორტზე ურთიერთობს, SFTP კი ცალკე მუშაობს. Upstream-ის ნაგულისხმევი მნიშვნელობებით Wings API 8080-ზეა, მისი SFTP მსმენელი 2022-ზე, პანელი კი 80-სა და 443-ზე.

ეს ხუთი-ექვსი სერვისია განახლებული სახით შესანახად, სერტიფიკატი პანელის hostname-ისთვის და Docker image თითო თამაშზე. გაითვალისწინე დაახლოებით 1 GB მეხსიერება, სანამ რომელიმე გეიმ სერვერი გაეშვება. 24 GB VDS-ზე ეს დამრგვალების ცდომილებაა; 8 GB დონეზე ეს შენი მანქანის მერვედია, დახარჯული ინფრასტრუქტურაზე და არა მოთამაშეებზე. რას გაძლევს Pterodactyl პანელი არქიტექტურას უფრო დეტალურად ფარავს.

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

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

FAQ#

რამდენი გეიმ სერვერი ეტევა ერთ VDS-ზე?

დათვალე სწრაფი thread-ები და არა გიგაბაიტები. გეიმ სერვერების უმეტესობა ერთ thread-ზე ასიმულირებს, ამიტომ ორი vCPU-ს მქონე მანქანა კომფორტულად უშვებს ორს ან სამს, რომლებსაც პიკი სხვადასხვა დროს აქვთ, ექვსი vCPU-სი კი - ხუთს ან ექვსს. მეხსიერება მკაცრ ჭერს ადგენს; CPU ადგენს იმას, რომელსაც ნამდვილად იგრძნობ.

შეიძლება ყველა ერთ IP მისამართს იყენებდეს?

დიახ. ეს ნორმალური მოწყობაა და ამიტომაა პორტების რუკა მნიშვნელოვანი. თითოეული სერვერი ერთსა და იმავე მისამართზე სხვადასხვა პორტს იკავებს, მოთამაშეები კი address:port-ით უერთდებიან. თითო პროტოკოლზე მხოლოდ ერთ სერვერს შეიძლება ჰქონდეს კონკრეტული პორტის ნომერი.

უნდა გამოვიყენო Docker თითოეული სერვერისთვის?

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

საკმარისია tmux სერვერის გასაშვებად?

იმისთვის, რასაც თვალს ადევნებ - დიახ. ყველაფრისთვის, რაც მუდმივია - არა. tmux სესია გადატვირთვის შემდეგ არ ირთვება და ავარიის შემდეგ არ გადაიტვირთება. გამოიყენე systemd unit და tmux დატოვე კონსოლისთვის, თუ თამაშს RCON არ აქვს.

რა ხდება, როცა ერთი სერვერი მთელ მეხსიერებას იყენებს?

ლიმიტების გარეშე ბირთვი ირჩევს მანქანაზე ყველაზე დიდ პროცესს და კლავს მას, რაც ხშირად ის არ არის, რომელმაც დააშავა. თითო unit-ზე MemoryMax-ით დამნაშავე საკუთარ ჭერს ეჯახება და მხოლოდ ის კვდება. დააყენე ლიმიტები.

ეს უფრო იაფია, ვიდრე ცალკე მართვადი გეგმები?

ზოგჯერ. სამ სერვერამდე თითქმის არასოდეს, საათების დათვლის შემდეგ. ხუთს ზემოთ, ჩვეულებრივ, დიახ, რადგან მეხსიერება იყრის თავს და მანქანას იხდი და არა ხუთ ცალკე ჭერს. დათვალე ორივე, შემდეგ VDS-ის მხარეს დაამატე თვეში საათების რეალისტური რაოდენობა და მხოლოდ ამის შემდეგ შეადარე.