Veeam Log Diving კომპონენტები და ლექსიკონი

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

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

რატომ სტატიების სერია და რატომ არ აღწერე ყველაფერი ერთდროულად?

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

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

ლექსიკონი და ჟარგონი

აქ, უპირველეს ყოვლისა, ღირს ბოდიშის მოხდა რუსული ენის სიწმინდის ჩემპიონებს და ოჟეგოვის ლექსიკონის მოწმეებს. ჩვენ ყველას ძალიან გვიყვარს ჩვენი მშობლიური ენა, მაგრამ დაწყევლილი IT ინდუსტრია მუშაობს ინგლისურად. ისე, ჩვენ არ გამოვედით, მაგრამ ეს მოხდა ისტორიულად. ჩემი ბრალი არ არის, ის თვითონ მოვიდა (გ)

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

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

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

მასპინძელი (მასპინძელი): ვირტუალიზაციის სამყაროში ეს არის მანქანა ჰიპერვიზორით. ფიზიკური, ვირტუალური, ღრუბელი - არ აქვს მნიშვნელობა. თუ რამე მუშაობს ჰიპერვიზორით (ESXi, Hyper-V, KVM და ა.შ.), მაშინ ამ „რაღაცას“ ჰქვია ჰოსტი. იქნება ეს კლასტერი ათი თაროებით თუ თქვენი ლეპტოპი ერთნახევარი ვირტუალური აპარატის ლაბორატორიით - თუ ჰიპერვიზორი გაუშვით, გახდით მასპინძელი. რადგან ჰიპერვიზორი მასპინძლობს ვირტუალურ მანქანებს. არსებობს ამბავიც კი, რომ VMware-ს ერთ დროს სურდა მიეღწია სიტყვა ჰოსტის მტკიცე ასოციაციის მიღწევა ESXi-სთან. მაგრამ მან არ გააკეთა.

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

ადგილობრივი ჟარგონიდან (ამ შემთხვევაში, აკრონიმებიც კი), აქ შეგახსენებთ, რომ VMware არის VI, vSphere არის VC და Hyper-V არის HV.

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

Რისთვის? Მე არ ვიცი.
Guest OS, შესაბამისად, სტუმრის აპარატის ოპერაციული სისტემა. Და ასე შემდეგ.

სარეზერვო/რეპლიკაციის სამუშაო (jobA): სუფთა Wim ჟარგონი, რომელიც აღნიშნავს ზოგიერთ დავალებას. სარეზერვო სამუშაო == სარეზერვო სამუშაო. არავის გაუგონია, როგორ უნდა თარგმნოს ლამაზად რუსულად, ამიტომ ყველა ამბობს "JobA". ბოლო მარცვალის აქცენტით.

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

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

კონსოლიდაცია (კონსოლიდაცია): ტერმინი, რომელიც გამოჩნდა ESXi 5.0-ში. ვარიანტი სნეპშოტის მენიუში, რომელიც იწყებს ე.წ. ეს არის კადრები, რომლებიც ფიზიკურად ხელმისაწვდომია, მაგრამ გამოვარდა ნაჩვენები ლოგიკური სტრუქტურიდან. თეორიულად, ეს პროცესი არ უნდა იმოქმედოს Snapshot მენეჯერში გამოტანილ ფაილებზე, მაგრამ ყველაფერი შეიძლება მოხდეს. კონსოლიდაციის პროცესის არსი იმაში მდგომარეობს, რომ სნეპშოტის (ბავშვის დისკის) მონაცემები იწერება მთავარ (მშობლის) დისკზე. დისკების გაერთიანების პროცესს ეწოდება შერწყმა. თუ კონსოლიდაციის ბრძანება გაიცა, მაშინ snapshot ჩანაწერი შეიძლება ამოღებულ იქნას მონაცემთა ბაზიდან, სანამ snapshot გაერთიანდება და წაიშლება. და თუ სნეპშოტის წაშლა რაიმე მიზეზით ვერ მოხერხდა, მაშინ ჩნდება ეს იგივე ობოლი კადრები. სნეპშოტებთან მუშაობის შესახებ, VMware-ს აქვს კარგი KB. და ჩვენ ასევე რატომღაც მათ შესახებ დაწერა ჰაბრეზე.

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

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

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

 Snapshot (SnapshOt): ოქსფორდის გრამატიკის მოყვარულებს ურჩევნიათ თქვან ვინ არის სნეპშოტი და ვინ არის სნეპშოტი, მაგრამ გაუნათლებელი უმრავლესობა სარგებლობს უფრო დიდი მასით. თუ ვინმემ არ იცის, ეს არის ტექნოლოგია, რომელიც საშუალებას გაძლევთ აღადგინოთ დისკის მდგომარეობა დროის გარკვეულ მომენტში. ეს კეთდება ან I/O ოპერაციების დროებით გადამისამართებით მთავარი დისკიდან - შემდეგ მას დაერქმევა RoW (Redirect on Write) სნეპშოტი - ან გადაწერადი ბლოკების გადაადგილებით თქვენი დისკიდან მეორეზე - ამას დაერქმევა CoW (Copy on Write). ) ფოტოსურათი. ამ ფუნქციების გამოყენების ფართო შესაძლებლობების წყალობით, Veeam-ს შეუძლია სარეზერვო მაგიის შესრულება. მკაცრად რომ ვთქვათ, არა მხოლოდ ისინი, არამედ ეს არის შემდეგი რელიზების საკითხი.

ამ ტერმინის ირგვლივ ქაოსია ESXi-ს დოკუმენტაციასა და ჟურნალებში და სნეპშოტების ხსენების კონტექსტში შეგიძლიათ იპოვოთ თავად სნეპშოტები, გადაკეთება ჟურნალი და დელტა დისკიც კი. Veeam-ის დოკუმენტაცია არ შეიცავს ასეთ დაშლას და სნეპშოტი არის სნეპშოტი, ხოლო ხელახალი ჟურნალი არის ზუსტად REDO ფაილი, რომელიც შექმნილია დამოუკიდებელი არა მუდმივი დისკის მიერ. REDO ფაილები იშლება, როდესაც ვირტუალური მანქანა გამორთულია, ამიტომ მათი დაბნეულობა სნეპშოტებთან არის წარუმატებლობის გზა.

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

დავალება (დავალება): ეს არის თითოეული ცალკეული მანქანის დამუშავების პროცესი სამუშაოს ფარგლებში. ანუ: თქვენ გაქვთ სარეზერვო სამუშაო, რომელიც მოიცავს სამ მანქანას. ეს ნიშნავს, რომ თითოეული მანქანა დამუშავდება, როგორც ცალკეული დავალების ნაწილი. საერთო ჯამში, იქნება ოთხი ჟურნალი: მთავარი სამუშაოსთვის და სამი ამოცანებისთვის. თუმცა, აქ არის მნიშვნელოვანი ნიუანსი: დროთა განმავლობაში სიტყვა „დავალება“ ზედმეტად ორაზროვანი გახდა. როდესაც ვსაუბრობთ ზოგად ჟურნალებზე, ვგულისხმობთ, რომ ამოცანა არის ზუსტად VM. მაგრამ არის „დავალებები“ როგორც პროქსიზე, ასევე საცავზე. აქ შეიძლება ნიშნავდეს ვირტუალურ დისკს, ვირტუალურ მანქანას და მთელ სამუშაოს. ანუ მნიშვნელოვანია კონტექსტი არ დავკარგოთ.

Veeam %name% სერვისი:  წარმატებული სარეზერვო ასლების სასარგებლოდ, ერთდროულად მუშაობს რამდენიმე სერვისი, რომელთა ჩამონათვალი შეგიძლიათ იხილოთ სტანდარტულ აღჭურვილობაში. მათი სახელები საკმაოდ გამჭვირვალედ ასახავს მათ არსს, მაგრამ თანასწორთა შორის არის ყველაზე მნიშვნელოვანი - Veeam Backup Service, რომლის გარეშეც დანარჩენი არ იმუშავებს.

VSS: ტექნიკურად, VSS ყოველთვის უნდა იყოს Microsoft Volume Shadow Copy Service. სინამდვილეში, მას ბევრი იყენებს, როგორც Application-Aware Image Processing-ის სინონიმი. რაც, რა თქმა უნდა, კატეგორიულად არასწორია, მაგრამ ეს არის ამბავი კატეგორიიდან „ნებისმიერ ჯიპს შეიძლება ეწოდოს ჯიპი და გაგიგებენ“.

ფანტასტიკური მორები და სად ცხოვრობენ

მინდა დავიწყო ეს თავი დიდი საიდუმლოს გამჟღავნებით - რა დროა ნაჩვენები ჟურნალებში?

გახსოვდეთ:

• ESXi ყოველთვის წერს ჟურნალებს UTC+0-ში.
• vCenter ინახავს ჟურნალებს თავისი დროის ზონის დროის მიხედვით.
• Veeam ინახავს ჩანაწერებს სერვერის დროისა და დროის სარტყელის მიხედვით.
• და მხოლოდ Windows-ის ღონისძიებები EVTX ფორმატში არ იტანჯება არაფერთან დაკავშირებული. გახსნისას, დრო ხელახლა გამოითვლება იმ მანქანისთვის, რომელზეც ისინი გაიხსნა. ყველაზე მოსახერხებელი ვარიანტი, თუმცა მასში სირთულეებია. ერთადერთი ხელშესახები სირთულე არის ლოკალების განსხვავება. ეს არის პრაქტიკულად გარანტირებული გზა წაუკითხავი ჟურნალებისკენ. დიახ, არსებობს ვარიანტები, თუ როგორ უნდა მოვეკიდოთ ამას, მაგრამ მოდით, არ ვიკამათოთ იმ ფაქტზე, რომ IT-ში ყველაფერი მუშაობს ინგლისურად და შევთანხმდეთ, რომ ყოველთვის დააყენოთ ინგლისური ლოკალი სერვერებზე. ოჰ გთხოვ. 

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

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

თუმცა, ოსტატი არ აგროვებს ყველა ამოცანის ჟურნალებს და, მაგალითად, თუ გჭირდებათ რესტავრატორის ჟურნალების შესწავლა, შეცდომით ან გაუმართაობით, თქვენი გზა დევს საქაღალდეში. %ProgramData%/Veeam/Backup. ეს არის მთავარი VBR logostore და %ProgramData% არის ფარული საქაღალდე და ეს კარგია. სხვათა შორის, ნაგულისხმევი მდებარეობის ხელახლა მინიჭება შესაძლებელია REG_SZ: LogDirectory ტიპის რეესტრის გასაღების გამოყენებით HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication ფილიალში.

Linux მანქანებზე, მუშა აგენტის ჟურნალები უნდა მოძებნოთ /var/log/VeeamBackup/თუ იყენებთ root ან sudo ანგარიშს. თუ არ გაქვთ ასეთი პრივილეგიები, მაშინ მოძებნეთ შესვლა /tmp/VeeamBackup. 

Veeam აგენტისთვის %OS_name% ჟურნალები უნდა მოძებნოთ %ProgramData%/Veeam/Endpoint (ან %ProgramData%/Veeam/Backup/Endpoint) და /var/log/veeam შესაბამისად.

თუ თქვენ იყენებთ Application-Aware Image Processing-ს (და სავარაუდოდ თქვენ იყენებთ), მაშინ სიტუაცია გარკვეულწილად გართულდება. დაგჭირდებათ ჩვენი დამხმარის ჟურნალები, რომლებიც ინახება თავად ვირტუალურ მანქანაში და VSS ჟურნალები. იმის შესახებ, თუ როგორ და სად მივიღოთ ეს ბედნიერება, დეტალურად წერია ეს მუხლი. და რა თქმა უნდა არსებობს ცალკე სტატია შეაგროვოს საჭირო სისტემის ჟურნალები. 

Windows-ის მოვლენები მოხერხებულად გროვდება შესაბამისად ეს HF. თუ თქვენ იყენებთ Hyper-V-ს, საქმე უფრო რთულდება, რადგან თქვენ ასევე დაგჭირდებათ მისი ყველა ჟურნალი Applications and Service Logs > Microsoft > Windows ფილიალიდან. მიუხედავად იმისა, რომ ყოველთვის შეგიძლიათ უფრო სულელური გზით წახვიდეთ და უბრალოდ აიღოთ ყველა ობიექტი %SystemRoot%System32winevtLogs-დან.

თუ რამე გაფუჭდა ინსტალაციის/განახლების დროს, ყველაფერი, რაც გჭირდებათ, შეგიძლიათ ნახოთ %ProgramData%/Veeam/Setup/Temp საქაღალდეში. თუმცა არ დავმალავ იმ ფაქტს, რომ OS-ის მოვლენებში შეგიძლიათ იპოვოთ უფრო სასარგებლო ინფორმაცია, ვიდრე ამ ჟურნალებში. დანარჩენი საინტერესო მდგომარეობს %Temp% -ში, მაგრამ ძირითადად არის ინსტალაციის ჟურნალები შესაბამისი პროგრამული უზრუნველყოფისთვის, როგორიცაა ბაზა, .Net ბიბლიოთეკები და სხვა. გაითვალისწინეთ, რომ Veeam დაინსტალირებულია msi-დან და მისი ყველა კომპონენტი ასევე დაინსტალირებულია ცალკე msi პაკეტების სახით, თუნდაც ეს არ იყოს ნაჩვენები GUI-ში. ამიტომ, თუ რომელიმე კომპონენტის ინსტალაცია ვერ მოხერხდა, მთელი VBR ინსტალაცია შეჩერდება. ამიტომ, თქვენ უნდა შეხვიდეთ ჟურნალებში და ნახოთ, რა გატეხა ზუსტად და რომელ მომენტში.

და ბოლოს, ლაიფ ჰაკი: თუ ინსტალაციის დროს მიიღებთ შეცდომას, არ იჩქაროთ დააწკაპუნოთ OK. ჯერ ვიღებთ ჟურნალებს, შემდეგ დააჭირეთ OK. ამ გზით თქვენ მიიღებთ ჟურნალს, რომელიც მთავრდება შეცდომის დროს, ბოლოს ნაგვის გარეშე.

და ეს ხდება, რომ თქვენ უნდა შეხვიდეთ vSphere ჟურნალებში. ოკუპაცია ძალიან უმადურობაა, მაგრამ, როცა ხელები აიჩეჩა, სხვა რაღაც უნდა გააკეთო. უმარტივეს ვერსიაში, ჩვენ გვჭირდება ჟურნალები ვირტუალური მანქანის მოვლენებით vmware.log, რომლებიც მდებარეობს მისი .vmx ფაილის გვერდით. უფრო რთულ შემთხვევაში, გახსენით Google და ჰკითხეთ, სად მდებარეობს თქვენი ჰოსტის ვერსიის ჟურნალები, რადგან VMware-ს უყვარს ამ ადგილის შეცვლა გამოშვებიდან გამოშვებამდე. Მაგალითად, სტატია 7.0-ისთვის, მაგრამ ამისთვის 5.5. vCenter ჟურნალებისთვის, გაიმეორეთ პროცედურა გუგლინგი. მაგრამ ზოგადად, ჩვენ დავინტერესდებით მასპინძელი ღონისძიებების ჟურნალები hostd.log, მასპინძელი ღონისძიებები, რომელსაც მართავს vCenter vpxa.log, ბირთვის ჟურნალები vmkernel.log და ავთენტიფიკაციის ჟურნალები auth.log. ისე, ყველაზე უგულებელყოფილ შემთხვევებში, SSO ჟურნალი, რომელიც დევს SSO საქაღალდეში, შეიძლება გამოდგება.

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

Veeam კომპონენტები

და როგორც ამ შესავალი სტატიის დასასრული, მოდით ვისაუბროთ ცოტა Veeam Backup & Replication-ის კომპონენტებზე. როდესაც ტკივილის მიზეზს ეძებთ, კარგი იქნება იმის გაგება, თუ როგორ მუშაობს პაციენტი.

ასე რომ, როგორც ყველამ იცის, Veeam Backup არის ეგრეთ წოდებული SQL-ზე დაფუძნებული აპლიკაცია. ანუ ყველა პარამეტრი, ყველა ინფორმაცია და ზოგადად ყველაფერი, რაც მხოლოდ ნორმალური ფუნქციონირებისთვისაა საჭირო - ეს ყველაფერი მის მონაცემთა ბაზაშია. უფრო სწორად, ორ მონაცემთა ბაზაში, თუ ვსაუბრობთ VBR და EM-ის თაიგულზე: VeeamBackup და VeeamBackupReporting, შესაბამისად. ასეც მოხდა: ჩვენ დავაყენეთ სხვა აპლიკაცია - ჩნდება სხვა მონაცემთა ბაზა. იმისათვის, რომ არ შეინახოთ ყველა კვერცხი ერთ კალათაში.

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

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

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

მაგრამ დაუბრუნდით სერვისების ჩამონათვალს. Veeam ბროკერის სერვისი. გამოჩნდა v9.5-ში (და ეს არ არის კრიპტო მაინერი, როგორც მაშინ ზოგი ფიქრობდა). აგროვებს ინფორმაციას VMware ჰოსტების შესახებ და ინარჩუნებს მის შესაბამისობას. ოღონდ მაშინვე ნუ აწარმოებთ გაბრაზებული კომენტარების დაწერას, რომ ჩვენ თვალთვალთ ვადევნებთ თქვენ და ყველა ლოგინს/პაროლს ვავრცელებთ taschmajor-ში. ყველაფერი გარკვეულწილად მარტივია. როდესაც თქვენ აწარმოებთ სარეზერვო ასლს, პირველი, რაც უნდა გააკეთოთ, არის ჰოსტთან დაკავშირება და მისი სტრუქტურის შესახებ ყველა მონაცემის განახლება. ეს საკმაოდ ნელი და შრომატევადი ამბავია. უბრალოდ დაიმახსოვრეთ რამდენი დრო სჭირდება თქვენ შესვლას ვებ ინტერფეისის საშუალებით და გახსოვდეთ, რომ იქ მხოლოდ ზედა ფენა ითვლება. სხვათა შორის, თქვენ კვლავ უნდა გახსნათ მთელი იერარქია სწორ ადგილას. ერთი სიტყვით, საშინელება. თუ თქვენ აწარმოებთ ათეულ სარეზერვო ასლს, მაშინ თითოეულ სამუშაოს ეს პროცედურა სჭირდება. თუ ვსაუბრობთ დიდ ინფრასტრუქტურაზე, მაშინ ამ პროცესს შეიძლება ათი წუთი ან მეტი დასჭირდეს. ამიტომ გადაწყდა ამისთვის გამოყოფილიყო ცალკე სერვისი, რომლის მეშვეობითაც შესაძლებელი იქნება ყოველთვის უახლესი ინფორმაციის მიღება. გაშვებისას ის ამოწმებს და სკანირებს ყველა დამატებულ ინფრასტრუქტურას, შემდეგ კი ცდილობს იმუშაოს მხოლოდ დამატებითი ცვლილებების დონეზე. ასე რომ, მაშინაც კი, თუ ერთდროულად აწარმოებთ ას სარეზერვო ასლს, ისინი ყველა მოითხოვენ ინფორმაციას ჩვენი ბროკერისგან და არ აწამებენ მასპინძლებს თავიანთი თხოვნით. თუ თქვენ გაწუხებთ რესურსები, მაშინ ჩვენი გათვლებით, 5000 ვირტუალურ მანქანას სჭირდება მხოლოდ 100 მბ მეხსიერება.

შემდეგი გვაქვს Veeam კონსოლი. ის არის Veeam Remote Console, ის არის Veeam.Backup.Shell. ეს არის იგივე GUI, რომელსაც ჩვენ ვხედავთ ეკრანის სურათებში. ყველაფერი მარტივია და აშკარაა - კონსოლის გაშვება შესაძლებელია ნებისმიერი ადგილიდან, სანამ ის არის Windows და არის კავშირი VBR სერვერთან. ერთადერთი, რისი თქმაც შეიძლება, არის ის, რომ FLR პროცესი დაამონტაჟებს წერტილებს ადგილობრივად (ანუ მანქანაზე, სადაც კონსოლი მუშაობს). ისე, Veeam Explorer-ის ასორტი ასევე იმუშავებს ადგილობრივად, რადგან ისინი კონსოლის ნაწილია. მაგრამ მან უკვე წამიყვანა ველურ ბუნებაში ...

კიდევ ერთი საინტერესო სერვისია Veeam სარეზერვო კატალოგის მონაცემთა სერვისი. სერვისების სიაში ცნობილია როგორც Veeam Guest Catalog Service. ის ეწევა ფაილური სისტემების ინდექსირებას სტუმრის აპარატებზე და ამ ცოდნით ავსებს VBRCatalog საქაღალდეს. იგი გამოიყენება მხოლოდ იქ, სადაც ჩართულია ინდექსირების ჩამრთველი. და აზრი აქვს ჩართვას მხოლოდ იმ შემთხვევაში, თუ თქვენ გაქვთ Enterprise Manager. ამიტომ, ჩემი გულის სიღრმიდან რჩევა: არ ჩართოთ ინდექსირება ისე, თუ არ გაქვთ EAT. დაზოგე ნერვები და მხარდაჭერის დრო.

ასევე სხვა მნიშვნელოვანი სერვისებიდან აღსანიშნავია Veeam Installer Service, რომლის დახმარებით ხდება საჭირო კომპონენტების მიწოდება და ინსტალაცია პროქსიებზე, საცავებსა და სხვა კარიბჭეებზე. ფაქტობრივად, ის საჭირო .msi პაკეტებს გადააქვს სერვერებზე და აინსტალირებს. 

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

ცალკე, მინდა აღვნიშნო მნიშვნელოვანი რამ, რაზეც კლიენტები ხშირად რეაგირებენ - ეს არის განსხვავება სერვისებისა და ინფორმაციის ვერსიებში, პროგრამებისა და ფუნქციების სნეპ-ინში. დიახ, სია იგივე იქნება, მაგრამ ვერსიები შეიძლება სრულიად განსხვავებული იყოს. ვიზუალური თვალსაზრისით არც ისე მაგარია, მაგრამ თუ ყველაფერი სტაბილურად მუშაობს, სრულიად ნორმალურია. მაგალითად, ინსტალერის სერვისისთვის, ვერსიის ნომერი ბევრად ჩამორჩება მეზობელებს. საშინელება და კოშმარი? არა, რადგან ის არ არის სრულად დაინსტალირებული, მაგრამ მისი DLL უბრალოდ განახლებულია. Patch v9.5 U4-ში ტექნიკური მხარდაჭერის კოშმარი მოხდა: განახლების დროს ყველა სერვისმა მიიღო ახალი ვერსიები, გარდა ყველაზე მნიშვნელოვანისა. U4b პატჩში სატრანსპორტო სერვისმა ყველა დანარჩენს ორი ვერსიით გადაუსწრო (ციფრების მიხედვით ვიმსჯელებთ). და ეს ასევე ნორმალურია - მასში სერიოზული შეცდომა იქნა ნაპოვნი, ამიტომ მან მიიღო ბონუს განახლება დანარჩენებთან შედარებით. ასე რომ შევაჯამოთ: ვერსიების განსხვავებები შეიძლება იყოს პრობლემა, მაგრამ თუ არის განსხვავება და ყველაფერი გამართულად მუშაობს, მაშინ ალბათ ასეც უნდა იყოს. მაგრამ არავინ გიკრძალავთ ამის გარკვევას ტექნიკურ მხარდაჭერაში.

ეს იყო ე.წ. სავალდებულო ან სავალდებულო მომსახურება. და არის დამხმარეების მთელი თაიგული, როგორიცაა Tape Service, Mount Service, vPowerNFS Service და ა.შ.

Hyper-V-სთვის, ზოგადად, ყველაფერი იგივეა, მხოლოდ არის სპეციფიკა Veeam Backup Hyper-V ინტეგრაციის სერვისი და თქვენი საკუთარი დრაივერი CBT-თან მუშაობისთვის.

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

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

ჯერჯერობით სულ ესაა

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

წყარო: www.habr.com