BranchCache VPN-ის ფაილური გაზიარებისთვის: როდის ეხმარება და როდის არა

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

იგივე გაზიარება, სამი განსხვავებული საჩივარი

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

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

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

განაწილებული ქეში: VPN პული ფილიალის LAN არ არის

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

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

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

ჰოსტირებული ქეში: განლაგება წყვეტს, დაეხმარება თუ არა

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

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

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

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

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

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

რა აღწევს ჯერ კიდევ წყაროს

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

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

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

მიიღეთ ის ორი მოძიებით და ერთი ატვირთვით

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

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

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