დაგეგმილი ამოცანები, რომლებიც ყველა გეიმ სერვერს სჭირდება

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

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

როგორ აიგება გრაფიკი: cron, ამოცანები და დაყოვნებები#

cron გამოსახულება არის ხუთი ველი, გამოყოფილი ჰარებით. ის დრო არ არის; ეს შაბლონია, რომელსაც საათი ყოველ წუთს ადარებენ.

0 5 * * *      05:00 every day15 4 * * *     04:15 every day0 */6 * * *    every six hours, on the hour*/15 * * * *   every fifteen minutes0 5 * * 1      05:00 on Mondays30 3 * * 0     03:30 on Sundays0 5 1 * *      05:00 on the first of the month

ორი მახე. პირველი: */5 წუთის ველში ნიშნავს ყოველ ხუთ წუთში; მარტოხელა 5 ნიშნავს საათის მერვე წუთზე, ერთხელ. მათი აღრევა იძლევა ან სამუშაოს, რომელიც თითქოს არასდროს სრულდება, ან სამუშაოს, რომელიც დღეში 288-ჯერ სრულდება. მეორე: როცა თვის დღეც და კვირის დღეც შეზღუდულია, cron სამუშაოს ასრულებს, როცა რომელიმე ემთხვევა და არა ორივე. 0 5 13 * 5 არ არის „პარასკევი, 13-ე“, ეს არის „ყოველი თვის მე-13 და ყოველი პარასკევი“. დატოვე ერთ-ერთი *-ად, თუ ეს არ გულისხმობ.

დროის სარტყელს იმაზე მეტი მნიშვნელობა აქვს, ვიდრე ხალხს ჰგონია. გრაფიკი პანელის საათზე მუშაობს და არა შენი ლეპტოპის, ამიტომ შეამოწმე, რას აჩვენებს ინტერფეისი, სანამ ივარაუდებ, რომ 05:00 შენი 05:00-ია. და ნურაფერს დაგეგმავ 02:00-სა და 03:00-ს შორის: ზონაში, რომელიც ზაფხულის დროს იცავს, ამ ფანჯარაში სამუშაოები წელიწადში ერთ ღამეს ორჯერ სრულდება და მეორე ღამეს საერთოდ არა. 04:00 და 05:00 უსაფრთხოა. Cron გამოსახულებები განმარტებული სინტაქსს უფრო დეტალურად შლის, მათ შორის შემოკლებებს, რომლებიც ყველგან არ არის მხარდაჭერილი - დაწერე ხუთი ველი და არასდროს გაგიკვირდება.

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

ღამის თანმიმდევრობა, წუთ-წუთ#

აი სრული მოწყობა Minecraft სერვერისთვის, როგორც ერთი გრაფიკი 0 4 * * *-ზე, სადაც დაყოვნებები აკეთებს საქმეს.

პრინციპი მარტივია: გამოაცხადე, გააჩერე, დააკოპირე, გაათავისუფლე, restart. რიცხვები შენია დასარეგულირებლად - 3 GB სამყაროს backup ამოცანასა და save-on-ს შორის უფრო დიდი დრო სჭირდება, ვიდრე 300 MB-ს - მაგრამ თანმიმდევრობა არ იცვლება.

ორი შეცდომა, რომლის დასახელებაც ღირს. backup-ის იმავე წუთში აღება, რომელშიც restart, გაძლევს backup-ს სერვერისა, რომელიც ითიშება. და save-off შესაბამისი save-on-ის გარეშე მოგვიანებით სერვერს restart-მდე შენახვის უნარს ართმევს, რაც ამ გრაფიკზე კარგადაა და კატასტროფულია იმაზე, რომელიც restart-ით არ მთავრდება. თუ დარწმუნებული არ ხარ, save-off საერთოდ გამოტოვე: save-all flush მარტო დიდი გაუმჯობესებაა არაფერთან შედარებით.

ოთხი გრაფიკი, რომელიც უმეტეს სერვერს უნდა ჰქონდეს#

ყველაფერი დანარჩენი მოაშორე და ესენი ისინია, რომლებიც თავს იხდიან.

1. ღამის restart. დიდხანს მომუშავე გეიმ სერვერები აგროვებენ: entity-ებს, chunk-ის მონაცემებს, მეხსიერების ფრაგმენტაციას, plugin-ებს, რომლებიც ნელა ჟონავს. restart 05:00-ზე არავის უჯდება არაფერი და ყველაფერს ანულებს. ეს ერთი გრაფიკი „რამდენიმე დღის შემდეგ ნელდება“ ჩივილებს იმაზე მეტს აღკვეთს, ვიდრე ნებისმიერი აპარატურის ცვლილება. რას მალავს ის და როდის არის მცდარი პასუხი, არის თემა restart გრაფიკები, რომლებიც გეხმარება.
2. Backup მანამდე. არა იმავე მომენტში - მანამდე, save-ით შუაში, როგორც ზემოთ. ორსლოტიან გეგმაზე ეს ბრუნავს: გუშინდელი ღამე გადაწერს გუშინწინდელს, სწორედ ამიტომ უნდა ინახავდეს მეორე სლოტი დაბლოკილ, ცნობილად კარგ ასლს და არა კიდევ ერთ ღამისას. Backup-ები, რომლებიც მართლა აღდგება ფარავს შენახვის არითმეტიკას.
3. გაფრთხილება მანამდე. restart, რომლის შესახებაც არავის უთქვამს, ჩამოვარდნისგან არ განირჩევა და მოთამაშეები მას ჩამოვარდნად აცხადებენ. ორი შეტყობინება, თხუთმეტი და ხუთი წუთით ადრე, საკმარისია.
4. რაღაც შენი თამაშისთვის სპეციფიკური. save ბრძანება, wipe, მონაცემთა ბაზის dump, რუკის ცვლა. ქვემოთ ცხრილი საწყისი წერტილია.

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

ბრძანებები, რომლებიც ღირს დაგეგმვად, თამაშების მიხედვით#

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

Valheim ის არის, რაც ხალხს უკვირს. dedicated server-ს ბრძანების ინტერფეისი საერთოდ არ აქვს, ამიტომ flush ნაბიჯი შეუძლებელია და გრაფიკი backup-ია, შემდეგ restart, იმის იმედით, რომ სუფთა გაჩერება სამყაროს ჩამოსვლისას ინახავს. ეს ასევე ნიშნავს, რომ backup თავად შეიძლება ცოცხალ თამაშს სრული -saveinterval-ით ჩამორჩეს, რაც არგუმენტია ამ მნიშვნელობის შესამცირებლად - იხილე Valheim dedicated server-ის გზამკვლევი.

Rust სერვერისთვის wipe საკუთარ რიტმზე მიდის და არა ღამისაზე, და ის იმდენადვე community-ს გადაწყვეტილებაა, რამდენადაც ტექნიკური: Rust-ის wipe-ები მოთამაშეების დაკარგვის გარეშე ფარავს დროს. ყველაფრისთვის, რასაც მონაცემთა ბაზა უდგას - FiveM framework, Minecraft ეკონომიკა, ვებ აპლიკაცია - dump საკუთარ გრაფიკს ეკუთვნის, backup-მდე რამდენიმე წუთით ადრე, რომ არქივმა ის აიღოს.

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

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

• მონაცემთა ბაზის dump. კონსოლის ბრძანება, რომელიც pg_dump-ს ან mongodump-ს სერვერის საქაღალდეში უშვებს 04:05-ზე, რომ 04:15-ის backup-მა ის დააარქივოს და მანქანიდან გაიტანოს. ბრძანებები და flag-ები არის მონაცემთა ბაზის backup-ები და აღდგენა.
• Framework-ის საკუთარი scheduler. Laravel-ის schedule:run ელის, რომ ყოველ წუთს გამოიძახებენ, რაც */1 * * * *-ის კანონიერი გამოყენებაა და ერთ-ერთი იმ იშვიათი სამუშაოთაგანი, რომელიც ასე ხშირად უნდა სრულდებოდეს. Django-სა და Rails-ის ეკვივალენტები იმავე ფორმისაა.
• ლოგების გასუფთავება. ყველაფერი, რაც ლოგის ფაილს სამუდამოდ წერს, საბოლოოდ დისკს გაავსებს, ხოლო სავსე დისკი ნელ სერვერზე გაცილებით უარესი ინციდენტია. ყოველკვირეული სამუშაო, რომელიც თოთხმეტ დღეზე ძველ ფაილებს შლის, არაფერი ღირს.
• Restart, მხოლოდ თუ ის ადგილს იმსახურებს. ჯანმრთელ Node ან Python პროცესს ღამის restart არ სჭირდება და მისი დამატება იმ გაჟონვას მალავს, რომელიც უნდა გაასწორო. თუ მეხსიერება ყოველდღე იზრდება, წაიკითხე Node-ის მეხსიერების ზღვრები განმარტებული, სანამ მის გარშემო დაგეგმავ.

ერთი რამ, რასაც არ დაგეგმავ: სერტიფიკატის განახლება. proxy სლოტზე სერტიფიკატი გაიცემა და ახლდება ავტომატურად 21-დღიან ფანჯარაში, და cron სამუშაო, რომელიც მას აწვება, არაფერ სასარგებლოს არ აკეთებს.

იმის შემოწმება, რომ გრაფიკი მართლა გაეშვა#

ჩუმი ჩავარდნა დაგეგმილი სამუშაოს ნორმალური ჩავარდნის რეჟიმია. cron არ ჩივის; ის უბრალოდ არაფერს აწარმოებს, და გრაფიკი, რომელიც ექვსი კვირაა ვარდება, ზუსტად ისე გამოიყურება, როგორც ის, რომელიც მუშაობდა.

სამი შემოწმება, ძალისხმევის მიხედვით:

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

გაუფრთხილდი %-ს, თუ cron-ს VDS-ზე წერ და არა პანელში: crontab-ში დაუეკრანებელი % ბრძანებას წყვეტს და ყველაფერი შემდეგ standard input ხდება. დათარიღებული ფაილის სახელი, როგორიცაა $(date +%F), იქ უნდა დაიწეროს $(date +\%F). ეს ერთი სიმბოლო იმ backup სამუშაოების საოცარ წილს ხსნის, რომლებიც არაფერს აწარმოებს.

თუ რამდენიმე სერვერს უშვებ, გადაანაწილე ისინი. ათი backup, რომელიც ერთსა და იმავე node-ზე 04:00-ზე იწყება, ერთსა და იმავე დისკს ეჯიბრება და თითოეული უფრო დიდხანს გრძელდება, ვიდრე უნდა. გაანაწილე ისინი საათზე: 5 4, 20 4, 35 4, 50 4. იგივე ეხება restart-ებს და სასიამოვნო გვერდითი ეფექტი აქვს, რომ არა შენი ყველა community ერთსა და იმავე წამს ბნელდება.

როცა გრაფიკი არასწორი ხელსაწყოა#

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

• Restart გაჟონვის დასამალად. კანონიერია დროებით, არაკეთილსინდისიერია როგორც სტრატეგია. ჩაწერე, რას მალავს; ეს ჩანაწერი არის bug report. რატომ იწყება შენი გეიმ სერვერი განუწყვეტლივ თავიდან მიზეზებს ჰყოფს.
• Backup-ის უფრო ხშირად აღება სწორად აღების ნაცვლად. ექვსი backup დღეში ორ სლოტში ნიშნავს, რომ შენი ყველაზე ძველი აღდგენადი მდგომარეობა რვა საათის წინანდელია. გუშინ შემოსული პრობლემა ახლა აღუდგენელია. სიღრმე სიხშირეს სჯობს, როცა დღეში ერთს გადალახავ.
• ჩავარდნის გარშემო დაგეგმვა. restart ყოველ ოთხ საათში, რადგან ყოველ ხუთში ვარდება, მოვლა არ არის, ეს უკუთვლაა. ის ასევე crash watcher-ს ეჯახება: საათში სამი restart, რომელიც არ მოგითხოვია, გაფრთხილებას აჩენს სერვერის გვერდზე და ავტომატურად ხსნის ticket-ს, ხოლო დაგეგმილი restart-ები არ ითვლება, ამიტომ დასათვლელი რეალური crash-ებია.

FAQ#

რომელ საათზე უნდა გაეშვას ღამის restart?

საათზე, როცა ყველაზე ცოტა მოთამაშეა, რაც ევროპული community-სთვის ჩვეულებრივ ადგილობრივი დროით 04:00-სა და 06:00-ს შორისაა. შეამოწმე შენი რიცხვები და ნუ გადმოიკოპირებ ნაგულისხმევს: სერვერს, რომლის მოთამაშეებიც უმეტესად სხვა დროის სარტყელშია, მისი მშვიდი საათი სრულიად სხვაგანაა. ზაფხულის დროის ცვლილების გამო თავი აარიდე 02:00-დან 03:00-მდე.

რამდენი გრაფიკი შეიძლება ჰქონდეს ერთ სერვერს?

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

ითვლება თუ არა დაგეგმილი restart crash-ის დადგენაში?

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

შეუძლია გრაფიკს მონაცემთა ბაზის dump-ის აღება?

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

რა ხდება, თუ ამოცანა ჯერ კიდევ მუშაობს, როცა შემდეგი იწყება?

არაფერი კარგი, ამისთვის არის დაყოვნებები. 20 GB სერვერის backup სამოც წამში არ სრულდება და მასზე დაჯდომილი restart ნაწილობრივ არქივს იძლევა. გაზომე შენი ამოცანები ერთხელ და დააყენე დაყოვნებები გაზომილი რიცხვებით და არა იმედით.

უნდა დავაგეგმო backup ყოველ განახლებამდე?

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