একাধিক Google Cloud প্রকল্প, একটি হাইব্রিড VPN? আগে সিদ্ধান্ত নিন
শেয়ার্ড VPC, পিয়ারিং ও একটি কানেক্টিভিটি হাব ভিন্ন মালিকানা-প্রশ্নের উত্তর দেয়। প্রতি প্রকল্পে একটি VPN স্থাপনের আগে নেটওয়ার্কের সীমানা বেছে নিন।
একাধিক Google Cloud প্রকল্পের হাইব্রিড অ্যাক্সেস দরকার হলে স্বাভাবিক প্রবণতা হয় প্রতি প্রকল্পে একটি VPN, আর সেটি প্রায় সবসময়ই ভুল গঠন। প্রকল্পের মালিকানা ও প্যাকেট রাউটিং সম্পর্কিত হলেও ভিন্ন বিষয়, আর কাজে লাগে এমন আর্কিটেকচার আপনার প্রয়োজনীয় প্রশাসনিক সীমানা ধরে রেখে অভিপ্রেত প্রিফিক্সগুলিকে অফিস বা ডেটা সেন্টারে একটিমাত্র সুচিন্তিত পথ দেয়। এই যাচাইগুলি ঠিক করে দেয় আপনি আসলে কোন নেটওয়ার্ক মডেল চান, সেই ক্রমে যা পুনরায় কাজ এড়ায়। প্রতিটি যাচাই আলোচনা আগেই শেষ করতে পারে, আর সেটাই উদ্দেশ্য।
প্রকল্পের সীমানা স্বয়ংক্রিয়ভাবে নিজস্ব টানেল দাবি করে না।
যাচাই করুন শেয়ার্ড বস্তুটি নেটওয়ার্ক কি না
মালিকানা নিয়ে প্রশ্ন দিয়ে শুরু করুন, কানেক্টিভিটি নয়: কেন্দ্রীয় নেটওয়ার্ক মালিকানা কি এই ওয়ার্কলোডগুলি সমর্থন করতে পারে? উত্তর হ্যাঁ হলে এবং প্রতিষ্ঠানের উপযুক্ত কনফিগারেশন থাকলে, একটি হোস্ট প্রকল্প VPC, সাবনেট ও কানেক্টিভিটির মালিক হয়, আর সার্ভিস প্রকল্পগুলি নিজেদের অ্যাপ্লিকেশন রিসোর্সের মালিক হয়। সেই শেয়ার্ড নেটওয়ার্কে একটি Cloud VPN সংযোগ তখন অভিপ্রেত ওয়ার্কলোড প্রিফিক্সগুলিতে সেবা দিতে পারে, রাউটিং ও নিরাপত্তা নীতির অধীন ।
সংযুক্তি কী করে সে বিষয়ে সুনির্দিষ্ট থাকুন। একটি সার্ভিস প্রকল্প সংযুক্ত করলে তার বিদ্যমান স্বাধীন VPC হোস্ট নেটওয়ার্কে মিলিয়ে যায় না, এবং প্রতিটি রিসোর্স স্বয়ংক্রিয়ভাবে সরে যায় না। ওয়ার্কলোড সংযুক্তি, অনুমতি, অ্যাড্রেস স্পেস ও DNS সবই আর্কিটেকচারের অংশ, সেটিংয়ের ফল নয়। সংযুক্তিকে আগে অনুমতির পরিবর্তন আর পরে রাউটিংয়ের পরিবর্তন হিসেবে পড়ুন, কারণ দলগুলি সাধারণত কাটওভারের সময়ই পার্থক্যটি আবিষ্কার করে।
কেন্দ্রীয় মালিকানা সংশ্লিষ্ট দলগুলির কাছে গ্রহণযোগ্য না হলে এখানেই থামুন এবং বাকিটিকে পিয়ারিং বা হাব ডিজাইন হিসেবে দেখুন। যে দলের স্বাধীন নেটওয়ার্ক জীবনচক্র দরকার তার উপর Shared VPC চাপিয়ে দেওয়া প্রযুক্তিগত নামযুক্ত রাজনৈতিক সমস্যা তৈরি করে।
যাচাই করুন স্বাধীন VPC-গুলি স্বাধীন থাকতে পারে কি না
পিয়ারিং আলাদা VPC ধরে রাখে, আর ঠিক এজন্যই এটি সেই দলগুলিকে আকর্ষণ করে যারা নিজেদের অ্যাড্রেস প্ল্যান ও নিজেদের পরিবর্তন নিয়ন্ত্রণ চায়। ফাঁদটি হল পিয়ারিং ট্রানজিটিভ নয়: A-থেকে-B এবং B-থেকে-C পিয়ারিং নিজে থেকে B হয়ে A-থেকে-C রাউটিং তৈরি করে না। তিনটি প্রকল্পের একটি হাইব্রিড গন্তব্যে পৌঁছানো দরকার হলে আপনার পিয়ারিংয়ের শৃঙ্খল নয়, সুচিন্তিত বিনিময় পরিকল্পনা দরকার।
হাইব্রিড রিচেবিলিটি ভাগ করে নেওয়া নির্ভর করে নথিভুক্ত কাস্টম-রাউট বিনিময় এবং অভিপ্রেত 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 কেনা সেই মালিকানা-সিদ্ধান্তের বিকল্প নয়। এটি একই সিদ্ধান্ত, পরে নেওয়া, যে বিল ও রাউটিং টেবিলের উত্তরাধিকার পায় সে-ই নেয়।