რამდენიმე Google Cloud პროექტი, ერთი ჰიბრიდული VPN? ჯერ გადაწყვიტეთ
საერთო VPC, ფირინგი და კავშირის ცენტრი სხვადასხვა მფლობელობის კითხვას პასუხობს. აირჩიეთ ქსელის საზღვარი სანამ ერთ VPN-ს განათავსებთ თითოეული პროექტისთვის.
როცა რამდენიმე Google Cloud პროექტს ჰიბრიდული წვდომა სჭირდება, ინსტინქტი არის ერთი VPN თითოეული პროექტისთვის და ეს თითქმის ყოველთვის არასწორი ფორმაა. პროექტის მფლობელობა და პაკეტების მარშრუტიზაცია დაკავშირებული, მაგრამ განსხვავებული საკითხებია, და სასარგებლო არქიტექტურა ინარჩუნებს საჭირო ადმინისტრაციულ საზღვრებს და ამავდროულად განზრახ პრეფიქსებს აძლევს ერთ გააზრებულ გზას ოფისის ან მონაცემთა ცენტრისკენ. ეს შემოწმებები წყვეტს, რომელი ქსელური მოდელი გინდათ სინამდვილეში, იმ თანმიმდევრობით, რომელიც თავიდან აიცილებს ხელახლა მუშაობას. თითოეულ მათგანს შეუძლია დისკუსია ადრე დაასრულოს და ეს არის აზრი.
პროექტის საზღვარი ავტომატურად არ მოითხოვს საკუთარ გვირაბს.
შეამოწმეთ, არის თუ არა საერთო ობიექტი ქსელი
დაიწყეთ კითხვით მფლობელობაზე და არა კავშირზე: შეუძლია თუ არა ქსელის ცენტრალურ მფლობელობას ამ დატვირთვების მხარდაჭერა? თუ პასუხია დიახ და ორგანიზაციას აქვს შესაბამისი კონფიგურაცია, ჰოსტ პროექტი ფლობს VPC-ს, ქვექსელებს და კავშირს, ხოლო სერვისული პროექტები ფლობენ საკუთარ აპლიკაციის რესურსებს. ერთ Cloud VPN კავშირს იმ საერთო ქსელში შეუძლია შემდეგ მოემსახუროს განზრახ დატვირთვის პრეფიქსებს, მარშრუტიზაციისა და უსაფრთხოების პოლიტიკის დაცვით .
იყავით ზუსტი იმაში, რას აკეთებს ასოციაცია. სერვისული პროექტის მიმაგრება არ აერთიანებს მის არსებულ დამოუკიდებელ VPC-ს ჰოსტ ქსელში და არ გადააქვს ყველა რესურსი ავტომატურად. დატვირთვის მიმაგრება, ნებართვები, მისამართების სივრცე და DNS ყველა არქიტექტურის ნაწილია და არა პარამეტრის შედეგი. წაიკითხეთ ასოციაცია ჯერ როგორც ნებართვის ცვლილება, შემდეგ კი როგორც მარშრუტიზაციის ცვლილება, რადგან გუნდები განსხვავებას ჩვეულებრივ გადასვლის დროს აღმოაჩენენ.
თუ ცენტრალური მფლობელობა მონაწილე გუნდებისთვის მიუღებელია, აქ გაჩერდით და დანარჩენი განიხილეთ როგორც ფირინგის ან ცენტრის დიზაინი. Shared VPC-ის დაძალება ჯგუფზე, რომელსაც დამოუკიდებელი ქსელური სასიცოცხლო ციკლები სჭირდება, ქმნის პოლიტიკურ პრობლემას ტექნიკური სახელით.
შეამოწმეთ, შეუძლიათ თუ არა დამოუკიდებელ VPC-ებს დამოუკიდებლად დარჩენა
ფირინგი ინარჩუნებს ცალკეულ VPC-ებს და სწორედ ამიტომ იზიდავს გუნდებს, რომლებსაც საკუთარი მისამართების გეგმები და საკუთარი ცვლილებების კონტროლი სურთ. ხაფანგი ის არის, რომ ფირინგი არ არის ტრანზიტული: A-დან-B-მდე და B-დან-C-მდე ფირინგი თავისთავად არ ქმნის A-დან-C-მდე მარშრუტიზაციას B-ის გავლით. თუ სამ პროექტს ერთი ჰიბრიდული დანიშნულების ადგილის მიღწევა სჭირდება, გჭირდებათ გააზრებული გაცვლის გეგმა და არა ფირინგების ჯაჭვი.
ჰიბრიდული მიწვდომადობის გაზიარება ასევე დამოკიდებულია დოკუმენტირებულ მორგებული მარშრუტების გაცვლაზე და განზრახ Cloud Router განცხადებებზე. ფირინგის აქტიური სტატუსი ამტკიცებს, რომ ფირინგი არსებობს და არა იმას, რომ პრეფიქსები, რომლებიც თითოეულ მხარეს აინტერესებს, ოდესმე ექსპორტირებულა. შეამოწმეთ ექსპორტირებული დიაპაზონები ფირის ორივე მხარეს, იმ კონფიგურაციაში, რომელიც ექსპორტს აკეთებს, და შეადარეთ ისინი მისამართებს, რომლებსაც თქვენი დატვირთვები რეალურად იყენებენ. იქ არსებული შეუსაბამობა ყველაზე გავრცელებული მიზეზია იმისა, რომ ფირინგი ჯანსაღად გამოიყურება, პრეფიქსი კი მიუწვდომელი რჩება.
დაწერეთ მისამართების გეგმა ყველაფერზე ადრე. არაგადამკვეთი დიაპაზონები, მარშრუტები ყოველი განზრახ დანიშნულებისკენ და დაბრუნების განცხადებები სამი არტეფაქტია, რომლებზეც ეს მოდელი ცოცხლობს ან კვდება.
შეამოწმეთ, შეესაბამება თუ არა ცენტრის მოდელი ტოპოლოგიას
უფრო დიდი ან სხვაგვარად სეგმენტირებული დიზაინისთვის Google-ის Network Connectivity Center-ის მიმოხილვა აღწერს ცენტრისა და სხივის მოდელებს. წაიკითხეთ ის იმისთვის, რასაც მიმდინარე გამოშვება მხარს უჭერს და არა იმისთვის, რასაც დიაგრამა გულისხმობს: რომელი VPC და ჰიბრიდული კომბინაციები, რომელი მარშრუტების ოჯახები და რა პოლიტიკას უშვებს სხივის თითოეული ტიპი.
ცალსახად შეამოწმეთ მისამართების ოჯახი. დაგეგმვის მაგალითები უმეტეს სახელმძღვანელოში, მათ შორის ამაშიც, IPv4-ს ეხება, და ერთი სხივის ტიპისთვის არსებული ფუნქცია ავტომატურად არ ვრცელდება უცვლელად მეორეზე. თუ თქვენი გარემო ორმაგი დასტაა, ეს კითხვა მოდელის არჩევანს ეკუთვნის და არა მოგვიანებით მიგრაციას.
ქვემოთ მოცემული ცხრილი სამი მოდელის შეჯამებაა და კითხვა, რომელიც თითოეულს წყვეტს.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
შეამოწმეთ, რას არ იძლევა მარშრუტიზაცია
მარშრუტების გაცვლა ნდობის ყოვლისმომცველი მინიჭება არ არის. DNS-ის გადაწყვეტა, ფაირვოლის ნებართვა და აპლიკაციის ავტორიზაცია საკუთარ პასუხისმგებლობად რჩება და თითოეულ მათგანს უმეტეს ორგანიზაციაში სხვადასხვა მფლობელი აკონფიგურირებს. დიზაინი, რომელიც ვარაუდობს, რომ მიწვდომადობა ნიშნავს ავტორიზაციას, გაივლის კავშირის ტესტს და ჩავარდება უსაფრთხოების მიმოხილვაში.
დაადასტურეთ DNS-ის ისტორია თითოეული მოდელისთვისაც, რადგან ზონისა და გადაგზავნის მოწყობა განსხვავდება საერთო ქსელსა და ფირინგიან ქსელებს შორის. ერთ პროექტში გადაწყვეტილი კერძო სახელები მარშრუტს მეორეში არ მიჰყვება.
ჩაწერეთ გადაწყვეტილება და მისი მფლობელი
ცენტრალიზაცია გააკეთეთ იქ, სადაც ორგანიზაციას საერთო ქსელის მფლობელი სურს; ცალკე VPC-ები შეინახეთ იქ, სადაც ამას სასიცოცხლო ციკლი ან პოლიტიკა მოითხოვს. შემდეგ აირჩიეთ მხარდაჭერილი კავშირის ურთიერთობა და ჩაწერეთ რომელი აირჩიეთ, ვინ ფლობს საერთო ქსელს და რისი გამოცხადება შეუძლია თითოეულ პროექტს.
პროექტების დათვლა და თითოეულისთვის ერთი VPN-ის ყიდვა არ ცვლის იმ მფლობელობის გადაწყვეტილებას. ეს იგივე გადაწყვეტილებაა, მოგვიანებით მიღებული მის მიერ, ვინც ანგარიშს და მარშრუტიზაციის ცხრილს მემკვიდრეობით იღებს.