ჰიპერკონვერგირებული ხსნარი AERODISK vAIR. საფუძველია ARDFS ფაილური სისტემა

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

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

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

არის Aerodisk ამბავი შენახვის სისტემების შესახებ? ან რატომ დავიწყეთ თავიდან ჰიპერკონვერგენციის გაკეთება?

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

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

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

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

მთავარი თავდაპირველი ამოცანა იყო შეგვექმნა ჩვენი საკუთარი, თუმცა მარტივი, მაგრამ საკუთარი ფაილური სისტემა, რომელსაც შეეძლო ავტომატურად და თანაბრად ავრცელებდა მონაცემებს ვირტუალური ბლოკების სახით მე-n ნომერი კლასტერულ კვანძებზე, რომლებიც დაკავშირებულია ურთიერთდაკავშირებით Ethernet-ის საშუალებით. ამავდროულად, FS უნდა გაიზარდოს კარგად და მარტივად და იყოს დამოუკიდებელი მეზობელი სისტემებისგან, ე.ი. გაუსხვისდეს vAIR-ს „უბრალოდ შენახვის ობიექტის“ სახით.

პირველი vAIR კონცეფცია

ჩვენ განზრახ უარი ვთქვით მზა ღია წყაროს გადაწყვეტილებების გამოყენებას დაჭიმული შენახვის ორგანიზებისთვის (ceph, gluster, luster და მსგავსი) ჩვენი საკუთარი განვითარების სასარგებლოდ, რადგან ჩვენ უკვე გვქონდა მათთან მუშაობის დიდი გამოცდილება. რა თქმა უნდა, თავად ეს გადაწყვეტილებები შესანიშნავია და სანამ აეროდისკზე ვიმუშავებდით, მათთან ერთზე მეტი ინტეგრაციის პროექტი განვახორციელეთ. მაგრამ ერთია კონკრეტული ამოცანის განხორციელება ერთი მომხმარებლისთვის, პერსონალის მომზადება და, შესაძლოა, დიდი გამყიდველის მხარდაჭერის ყიდვა, და სულ სხვაა შექმნა ადვილად გამეორებადი პროდუქტი, რომელიც გამოყენებული იქნება სხვადასხვა ამოცანებისთვის, რაც ჩვენ, როგორც გამყიდველი, შეიძლება ჩვენც არ ვიცოდეთ ჩვენ შესახებ. მეორე მიზნისთვის, არსებული ღია კოდის პროდუქტები არ იყო ჩვენთვის შესაფერისი, ამიტომ გადავწყვიტეთ თავად შეგვექმნა განაწილებული ფაილური სისტემა.
ორი წლის შემდეგ, რამდენიმე დეველოპერმა (რომლებიც აერთიანებდნენ vAIR-ზე მუშაობას და კლასიკურ Engine შენახვის სისტემაზე მუშაობას) მიაღწიეს გარკვეულ შედეგს.

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

ჩვენ ძალიან არ შევწუხდით ფაილური სისტემის სახელწოდებით და მოკლედ ვუწოდეთ მას ARDFS (გამოიცანით რას ნიშნავს))

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

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

ჩაყვინთვის ARDFS ფაილურ სისტემაში

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

შენახვის სტრუქტურა

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

ARDFS აუზის თავზე ემატება ვირტუალური დისკები (ვირტუალური მანქანების შესანახი ობიექტები), რომლებიც აგებულია 4 მეგაბაიტის ზომის ვირტუალური ბლოკებისგან. ვირტუალური დისკები პირდაპირ ინახავს მონაცემებს. შეცდომების ტოლერანტობის სქემა ასევე დაყენებულია ვირტუალური დისკის დონეზე.

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

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

შენახვის ხარვეზების ტოლერანტობის სქემები

vAIR-ში ვირტუალური დისკებისთვის შეიძლება არსებობდეს შეცდომების შემწყნარებლობის ორი სქემა:

1) რეპლიკაციის ფაქტორი ან უბრალოდ რეპლიკაცია - ხარვეზების ტოლერანტობის ეს მეთოდი ისეთივე მარტივია, როგორც ჯოხი და თოკი. სინქრონული რეპლიკაცია ხორციელდება კვანძებს შორის 2 (2 ასლი კლასტერზე) ან 3 (3 ასლი, შესაბამისად). RF-2 საშუალებას აძლევს ვირტუალურ დისკს გაუძლოს კლასტერში ერთი კვანძის უკმარისობას, მაგრამ "ჭამს" სასარგებლო მოცულობის ნახევარს, ხოლო RF-3 გაუძლებს კლასტერში 2 კვანძის უკმარისობას, მაგრამ ინახავს 2/3-ს. სასარგებლო მოცულობა მისი საჭიროებისთვის. ეს სქემა ძალიან ჰგავს RAID-1-ს, ანუ RF-2-ში კონფიგურირებული ვირტუალური დისკი მდგრადია კლასტერში რომელიმე ერთი კვანძის წარუმატებლობის მიმართ. ამ შემთხვევაში მონაცემებით ყველაფერი კარგად იქნება და შესვლაც კი არ გაჩერდება. როდესაც დაცემული კვანძი დაუბრუნდება სერვისს, დაიწყება მონაცემთა ავტომატური აღდგენა/სინქრონიზაცია.

ქვემოთ მოცემულია RF-2 და RF-3 მონაცემების განაწილების მაგალითები ნორმალურ რეჟიმში და წარუმატებლობის სიტუაციაში.

ჩვენ გვაქვს ვირტუალური მანქანა 8MB უნიკალური (სასარგებლო) მონაცემების ტევადობით, რომელიც მუშაობს 4 vAIR კვანძზე. გასაგებია, რომ სინამდვილეში ნაკლებად სავარაუდოა, რომ იყოს ასეთი მცირე მოცულობა, მაგრამ სქემისთვის, რომელიც ასახავს ARDFS ოპერაციის ლოგიკას, ეს მაგალითი ყველაზე გასაგებია. AB არის 4 მბ ვირტუალური ბლოკი, რომელიც შეიცავს უნიკალურ ვირტუალურ მანქანას. RF-2 ქმნის ამ ბლოკების A1+A2 და B1+B2, შესაბამისად, ორ ასლს. ეს ბლოკები "განლაგებულია" კვანძებში, თავიდან აიცილებენ იმავე მონაცემების გადაკვეთას იმავე კვანძზე, ანუ ასლი A1 არ განთავსდება იმავე კვანძზე, როგორც ასლი A2. იგივე B1 და B2.

თუ ერთ-ერთი კვანძი ვერ ხერხდება (მაგალითად, კვანძი No3, რომელიც შეიცავს B1-ის ასლს), ეს ასლი ავტომატურად გააქტიურდება იმ კვანძზე, სადაც არ არის მისი ასლი (ანუ B2-ის ასლი).

ამრიგად, ვირტუალური დისკი (და შესაბამისად VM) ადვილად გადარჩება RF-2 სქემის ერთი კვანძის წარუმატებლობას.

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

2) წაშლის კოდირება ან წაშლის კოდირება (ასევე ცნობილია როგორც "ზედმეტი კოდირება", "წაშლის კოდირება" ან "ჭარბი კოდი") არსებობს ზემოთ მოცემული პრობლემის გადასაჭრელად. EC არის ზედმეტობის სქემა, რომელიც უზრუნველყოფს მონაცემთა მაღალ ხელმისაწვდომობას დისკზე დაბალი სივრცით რეპლიკაციასთან შედარებით. ამ მექანიზმის მუშაობის პრინციპი მსგავსია RAID 5, 6, 6P.

კოდირებისას, EC პროცესი ყოფს ვირტუალურ ბლოკს (ნაგულისხმევად 4MB) რამდენიმე პატარა „მონაცემთა ნაწილად“ EC სქემის მიხედვით (მაგალითად, 2+1 სქემა ყოფს თითოეულ 4MB ბლოკს 2 2MB ნაწილად). შემდეგი, ეს პროცესი წარმოქმნის „პარიტეტის ნაწილებს“ „მონაცემთა ნაჭრებისთვის“, რომლებიც არ აღემატება ერთ-ერთ ადრე დაყოფილ ნაწილს. დეკოდირებისას, EC წარმოქმნის გამოტოვებულ ნაწილებს მთელ კლასტერში „გადარჩენილი“ მონაცემების წაკითხვით.

მაგალითად, ვირტუალური დისკი 2 + 1 EC სქემით, დანერგილი 4 კლასტერულ კვანძზე, ადვილად გაუძლებს კლასტერში ერთი კვანძის უკმარისობას ისევე, როგორც RF-2. ამ შემთხვევაში ზედნადები უფრო დაბალი იქნება, კერძოდ, RF-2-ისთვის სასარგებლო სიმძლავრის კოეფიციენტი არის 2, ხოლო EC 2+1-ისთვის ეს იქნება 1,5.

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

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

ქვემოთ მოცემულია მაგალითი, იგივე 8 MB ვირტუალური მანქანით და 4 კვანძით, მაგრამ EC 2+1 სქემით.

ბლოკები A და B იყოფა ორ ნაწილად თითო 2 მბ (ორი რადგან 2+1), ანუ A1+A2 და B1+B2. რეპლიკასგან განსხვავებით, A1 არ არის A2-ის ასლი, ეს არის ვირტუალური ბლოკი A, დაყოფილია ორ ნაწილად, იგივე ბლოკი B. ჯამში ვიღებთ ორ კომპლექტს 4 მბ, რომელთაგან თითოეული შეიცავს ორ ორ მეგაბაიტიან ნაწილს. შემდეგი, თითოეული ამ კომპლექტისთვის, პარიტეტი გამოითვლება არაუმეტეს ერთი ნაწილის მოცულობით (ანუ 2 მბ), ჩვენ ვიღებთ დამატებით + 2 ცალი პარიტეტს (AP და BP). საერთო ჯამში გვაქვს 4×2 მონაცემი + 2×2 პარიტეტი.

შემდეგი, ნაწილაკები "განლაგებულია" კვანძებს შორის ისე, რომ მონაცემები არ იკვეთება მათ პარიტეტთან. იმათ. A1 და A2 არ იქნება იმავე კვანძზე, როგორც AP.

ერთი კვანძის გაუმართაობის შემთხვევაში (მაგალითად, ასევე მესამე), ჩამოვარდნილი ბლოკი B1 ავტომატურად აღდგება BP პარიტეტიდან, რომელიც ინახება No2 კვანძზე და გააქტიურდება იმ კვანძზე, სადაც არის არ არის B-პარიტეტი, ე.ი. BP-ის ნაჭერი. ამ მაგალითში ეს არის კვანძი No1

დარწმუნებული ვარ, მკითხველს აქვს შეკითხვა:

”ყველაფერი, რაც თქვენ აღწერეთ, დიდი ხანია დანერგილია როგორც კონკურენტების, ასევე ღია კოდის გადაწყვეტილებებში, რა განსხვავებაა თქვენს მიერ EC-ის დანერგვას ARDFS-ში?”

და შემდეგ იქნება ARDFS-ის საინტერესო თვისებები.

წაშლის კოდირება მოქნილობაზე ფოკუსირებით

თავდაპირველად, ჩვენ მივაწოდეთ საკმაოდ მოქნილი EC X+Y სქემა, სადაც X უდრის რიცხვს 2-დან 8-მდე და Y უდრის რიცხვს 1-დან 8-მდე, მაგრამ ყოველთვის X-ზე ნაკლები ან ტოლია. ეს სქემა მოწოდებულია. მოქნილობისთვის. მონაცემთა ნაწილების (X) რაოდენობის გაზრდა, რომლებზეც იყოფა ვირტუალური ბლოკი, საშუალებას გაძლევთ შეამციროთ ზედნადები ხარჯები, ანუ გაზარდოთ გამოსაყენებელი სივრცე.
პარიტეტული ნაწილების (Y) რაოდენობის გაზრდა ზრდის ვირტუალური დისკის საიმედოობას. რაც უფრო დიდია Y მნიშვნელობა, მით უფრო მეტი კვანძი შეიძლება ჩავარდეს კლასტერში. რა თქმა უნდა, პარიტეტული მოცულობის გაზრდა ამცირებს გამოსაყენებელი სიმძლავრის რაოდენობას, მაგრამ ეს სანდოობისთვის გადასახდელი ფასია.

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

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

ქვემოთ მოცემულია ცხრილი, რომელიც ადარებს რამდენიმე (არა ყველა შესაძლო) RF და EC სქემას.

ცხრილი გვიჩვენებს, რომ EC 8+7-ის ყველაზე „მწვავე“ კომბინაციაც კი, რომელიც ერთდროულად 7-მდე კვანძის დაკარგვას იძლევა კლასტერში, „ჭამს“ ნაკლებ გამოსაყენებელ ადგილს (1,875 2-ის წინააღმდეგ), ვიდრე სტანდარტული რეპლიკაცია და იცავს 7-ჯერ უკეთესად. , რაც ამ დამცავ მექანიზმს, თუმცა უფრო რთულს, ბევრად მიმზიდველს ხდის იმ სიტუაციებში, როდესაც აუცილებელია დისკზე შეზღუდული სივრცის პირობებში მაქსიმალური საიმედოობის უზრუნველყოფა. ამავდროულად, თქვენ უნდა გესმოდეთ, რომ X ან Y-ის ყოველი „პლიუსი“ იქნება დამატებითი შესრულების ზედნადები, ასე რომ, სამკუთხედში საიმედოობას, დაზოგვასა და შესრულებას შორის უნდა აირჩიოთ ძალიან ფრთხილად. ამ მიზეზით, ჩვენ ცალკე სტატიას მივუძღვნით კოდირების ზომის წაშლას.

ფაილური სისტემის საიმედოობა და ავტონომია

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

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

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

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

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

ვის სჭირდება ეს სასწაული?

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

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

როდის არის შენახვის სისტემა GCS-ზე უკეთესი?

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

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

ჯერ ერთი, მონაცემთა ცენტრები და IT ინფრასტრუქტურები, რომლებიც აშენებულია კლასიკური სქემით შენახვის სისტემებით, ადვილად ვერ აღდგება, ამიტომ ასეთი ინფრასტრუქტურის მოდერნიზაცია და დასრულება ჯერ კიდევ 5-7 წლის მემკვიდრეობაა.

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

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

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

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

და სად იმუშავებს ჰიპერკონვერგირებული გადაწყვეტილებები, ვიდრე შენახვის სისტემები?

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

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

რა არის ეს გადაწყვეტილებები?

1. ყველა სტანდარტული ინფრასტრუქტურის სერვისი (საქაღალდეების სერვისი, ფოსტა, EDMS, ფაილური სერვერები, მცირე ან საშუალო ERP და BI სისტემები და ა.შ.). ჩვენ ამას ვუწოდებთ "ზოგად გამოთვლას".
2. ღრუბლოვანი პროვაიდერების ინფრასტრუქტურა, სადაც საჭიროა სწრაფად და სტანდარტიზებული ჰორიზონტალურად გაფართოება და კლიენტებისთვის ვირტუალური მანქანების იოლად „მოჭრა“.
3. ვირტუალური დესკტოპის ინფრასტრუქტურა (VDI), სადაც ბევრი მცირე მომხმარებლის ვირტუალური მანქანა მუშაობს და ჩუმად „ცურავს“ ერთიან კლასტერში.
4. ფილიალების ქსელები, სადაც თითოეულ ფილიალს სჭირდება 15-20 ვირტუალური აპარატის სტანდარტული, ხარვეზების შემწყნარებელი, მაგრამ იაფი ინფრასტრუქტურა.
5. ნებისმიერი განაწილებული გამოთვლა (მაგალითად, დიდი მონაცემთა სერვისები). სადაც დატვირთვა მიდის არა "სიღრმეში", არამედ "სიგანეში".
6. სატესტო გარემო, სადაც დამატებითი მცირე შეფერხებები მისაღებია, მაგრამ არსებობს ბიუჯეტის შეზღუდვები, რადგან ეს ტესტებია.

ამ დროისთვის სწორედ ამ ამოცანებისთვის გავაკეთეთ AERODISK vAIR და სწორედ მათზე ვაკეთებთ ყურადღებას (ჯერჯერობით წარმატებით). ალბათ ეს მალე შეიცვლება, რადგან... სამყარო არ დგას.

ასე რომ ...

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

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

წყარო: www.habr.com