প্রতিটি গ্রাহকের জন্য একটিই ডিজাইন ব্যবহৃত হয়। ক্লাউড-নির্দিষ্ট পার্থক্যগুলো—যেমন কানেক্টিভিটি প্রোডাক্ট, মূল পরিষেবা, ডাটাবেস ইঞ্জিন—হলো কনফিগারেশনের বিষয়, নতুন করে ডিজাইন করা নয়। আর একারণেই মাত্র পাঁচ কার্যদিবসের মধ্যে কোড থেকে একটি এনভায়রনমেন্ট তৈরি করা সম্ভব হয়।
ছবিটি উপর থেকে পড়া
- ব্যবহারকারী এবং ইন্টিগ্রেশনগুলো erp.<customer domain> নামক একটি নামে এসে HTTPS, TLS 1.2 বা তার উচ্চতর সংস্করণের মাধ্যমে একটি WAF সহ লোড ব্যালান্সারে পৌঁছায়। এটিই প্রবেশের একমাত্র পাবলিক পথ।
- কমপক্ষে তিনটি ওয়ার্কার নোড, প্রতিটি অ্যাভেইলেবিলিটি জোনের জন্য একটি করে, ওয়েব ও এপিআই, পোস্টিং ইঞ্জিন, ASK অপারেটর এবং ওয়ার্কার ও জব পরিচালনা করে। একটি নোড বা পুরো একটি জোন নষ্ট হয়ে গেলেও ব্যবহারকারীদের পরিষেবা দেওয়ার জন্য সক্ষমতা অবশিষ্ট থাকে।
- গ্রাহকের পছন্দের ইঞ্জিন ও আকারের পরিচালিত ডেটাবেসটির অন্য একটি জোনে একটি সিনক্রোনাস স্ট্যান্ডবাই রয়েছে। একটি জোন ব্যর্থ হলে কোনো ক্ষতি হয় না: RPO ≈ 0।
- ডকুমেন্ট এবং অ্যাটাচমেন্টগুলো ডেটাবেসে নয়, বরং ভার্সনযুক্ত অবজেক্ট স্টোরেজে থাকে।
- বহির্গামী ট্র্যাফিক NAT-এর মাধ্যমে একটি অনুমোদিত তালিকায় প্রবেশ করে: ব্যাংক, ট্যাক্স ও ই-ইনভয়েসিং, পে-রোল, ইমেল, এআই ইঞ্জিন। এর বাইরে আর কিছু নয়।
- ব্যাকআপগুলো একটি পৃথক অ্যাকাউন্টে থাকা এয়ার-গ্যাপড ভল্টে একমুখীভাবে পাঠানো হয়।
প্রাইভেট এন্ডপয়েন্ট এবং ইন্টারনাল লোড ব্যালেন্সারকে ড্যাশ চিহ্ন দিয়ে আঁকা হয়েছে, কারণ এগুলো শুধুমাত্র প্রাইভেট অ্যাক্সেস ব্যবহার করা হলেই বিদ্যমান থাকে। শুধুমাত্র HTTPS অ্যাক্সেসের ক্ষেত্রে এগুলো তৈরি হয় না।
পাঁচটি নব, আর কিছুই না।
নোডের আকার; নোডের সংখ্যা (সর্বনিম্ন তিনটি); ডাটাবেস ইঞ্জিন ও তার আকার; Live DR অঞ্চল; এনভায়রনমেন্টের সংখ্যা। বাকি সবকিছুই রেফারেন্স আর্কিটেকচার।
কনফিগার করুন, ইন্টিগ্রেট করুন এবং তারপরেই কোড করুন।
সাধারণের চেয়ে উন্নত কোনো প্রয়োজনীয়তা কনফিগারেশনের মাধ্যমেই পূরণ করা হয়, যদি তা প্ল্যাটফর্মের সাথে আপগ্রেড করা যায়। অন্যথায়, ক্লাস্টারের বাইরে চলমান TRANXACT API-এর মাধ্যমে ইন্টিগ্রেশন করে তা করা হয়। শুধুমাত্র তখনই, একটি নিরাপত্তা ও প্রকৌশল পর্যালোচনার পর, ক্লাস্টারের ভেতরের কোড বা এজেন্ট বিবেচনা করা হয়; অনুমোদিত হলে তা সহনীয় এবং গ্রাহক-সমর্থিত হয়, এবং প্রত্যাখ্যাত হলে তা বাইরে চলে।
গ্রাহকের জন্য সরাসরি ডেটাবেস অ্যাক্সেসের কোনো ব্যবস্থা নেই — এটি উপলব্ধ নয় (DB_3.1.09) হিসেবে চিহ্নিত করা আছে। রিপোর্টিং এবং ইন্টিগ্রেশন TRANXACT API এবং এক্সট্র্যাক্টের মাধ্যমে সম্পন্ন হয়, যে কারণে একটি BI টুল API বা নির্ধারিত এক্সট্র্যাক্টের মাধ্যমে সংযুক্ত থাকে, কখনোই ডেটাবেস লগইনের মাধ্যমে নয়।
ক্যাল্ডারউডের বিআই টিম তাদের ডেটা ওয়্যারহাউসের জন্য একটি রিড-অনলি ডাটাবেস ইউজার চেয়েছে। এর সমাধান হলো একটি প্রাইভেট লিঙ্কের মাধ্যমে নির্ধারিত সময়ে ডেটা এক্সট্র্যাক্ট করা — তাদের ইন্টারফেস লিস্টে বিআই রো-টি হলো "keep, scheduled extract, private link"।
চেষ্টা করে দেখুন ক্যাল্ডারউডের মাস-শেষের সময়ে জোন ২-এর একটি ওয়ার্কার নোড বিকল হয়ে যায়। ব্যবহারকারীদের কী হবে, এবং এটি কি SLA-এর আওতায় পড়বে?
এর পডগুলোকে জোন ১ এবং ৩-এর নোডগুলোতে পুনঃনির্ধারিত করা হয়, যেগুলো লোড বহনের জন্য উপযুক্ত আকারের ছিল; ডাটাবেস প্রভাবিত হয় না, যদি না জোন ২ প্রাইমারি হিসেবে থাকে, সেক্ষেত্রে এটি RPO ≈ 0 সহ সিনক্রোনাস স্ট্যান্ডবাইতে ফেইলওভার করে। এটি শুধুমাত্র তখনই SLA-এর আওতায় গণনা করা হয়, যখন মাসের প্রাপ্যতা টিয়ার লক্ষ্যমাত্রা পূরণ করতে ব্যর্থ হয়।