საიდან მოდის VPN სერვერის დისკის ზრდა და როგორ შევზღუდოთ ის

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

იპოვეთ გაზრდილი საცავი და ტემპი, რომლითაც ის გაიზარდა

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

df -h /var
df -i /var

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

journalctl --disk-usage

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

რას უკეთებს როტაცია ღია ფაილს

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

lsof +L1 | head

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

logrotate -d /etc/logrotate.conf

სად უნდა იყოს ლიმიტი და რამდენად დიდი უნდა იყოს

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

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

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

გადატვირთვის შემდეგ შეამოწმეთ ლიმიტი

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

systemctl restart systemd-journald
journalctl --disk-usage

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

შეადარეთ შემდეგი გაზომვა ამას

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

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

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