RRAS Azure VM-ზე მხარდაჭერილი არ არის: შეამოწმეთ დიზაინამდე

თქვენ ხსნით პორტალს, ათავსებთ Windows Server 2022-ს ქვექსელში და Remote Access როლი უპრობლემოდ ინსტალდება. ეს თანმიმდევრობა ამტკიცებს, რომ ინსტალატორი მუშაობს და არა ის, რომ Microsoft ამ კონფიგურაციას მხარს უჭერს. Azure ვირტუალური მანქანებისთვის გამოქვეყნებული სერვერული პროგრამული უზრუნველყოფის მხარდაჭერის სახელმძღვანელო RRAS-ს Windows Server-ის იმ ფუნქციებს შორის ასახელებს, რომლებიც Azure VM-ებზე არ არის მხარდაჭერილი, და ეს არქიტექტურული გადაწყვეტილებაა და არა ხარვეზების აღმოფხვრის დეტალი. ამომავალი გვირაბი განლაგებას მხარდაჭერის საზღვრის შიგნით არ გადააქვს.

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

დაიწყეთ მხარდაჭერის გვერდიდან და არა ლაბორატორიიდან

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

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

გაყავით OS-ის მხარდაჭერა როლებისა და ფუნქციების მხარდაჭერისგან

იგივე სახელმძღვანელო Network Policy and Access Services-ს მხარდაჭერილ როლებში ასახელებს, ხოლო RRAS-ს ცალკე, მხარდაუჭერელად. ეს ორი ჩანაწერი სხვადასხვა რამეს აღწერს და მათი გაერთიანება „დისტანციური წვდომა მხარდაჭერილია“ ფორმაში სწორედ ის გზაა, რომლითაც პროექტი არასწორი წაკითხვის საფუძველზე მტკიცდება. ოპერაციული სისტემის მხარდაჭერა არაფერს ამბობს ფუნქციაზე, რომელსაც საკუთარი სტრიქონი აქვს.

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

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

ჩაწერეთ, რა უნდა გააკეთოს დიზაინმა რეალურად

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

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

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

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

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

Azure-ის მართული კავშირის სერვისები და მომწოდებლების მიერ მხარდაჭერილი ქსელური ვირტუალური მოწყობილობები ორივე ერთი და იმავე სიის მიხედვით უნდა შეფასდეს. ნუ ჩათვლით, რომ რომელიმე მათგანი RRAS VM-ის პირდაპირი ეკვივალენტია მხოლოდ იმიტომ, რომ IPsec-ის დასრულება შეუძლია: NAT მოდელი და მარშრუტების საკუთრება და მაღალი ხელმისაწვდომობის დიზაინი წყვეტს, როგორ უკავშირდებიან არსებული საიტები და სად ბრუნდებიან მათი პასუხები. შეაფასეთ თითოეული კანდიდატი ქაღალდზე სიის მიხედვით და ჩაწერეთ, რომელ მოთხოვნებს არ აკმაყოფილებს, რადგან სწორედ ეს ჩანაწერი ხდის არჩევანს მოგვიანებით გადამოწმებადს.

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

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

თუ RRAS VM უკვე მუშაობს

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

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

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