یہ دستاویز آرکیٹیکٹس اور ان لوگوں کے لیے ہے جو آپریشنز اور انتظامی ٹیموں میں کام کرتے ہیں۔ دستاویز ایک مثالی پیٹرن کی وضاحت کرتی ہے جسے آپ گوگل کلاؤڈ میں اپنی اپنی تعیناتیوں کے لیے استعمال کر سکتے ہیں۔

اس پیٹرن میں، کلاؤڈ DNS ٹریفک کو کمپیوٹ انجن انسٹینسز کو منظم مثالی گروپس میں بھیجتا ہے جو مواد کو پیش کرتے ہیں۔ بندش کی صورت میں، آپ کلاؤڈ DNS زون کو اپ ڈیٹ کرتے ہیں اور Cloud Storage میں ایک مستحکم سائٹ پر ناکام ہو جاتے ہیں

اس ٹیوٹوریل کو مکمل کرنے کے لیے، آپ کو ایک رجسٹرڈ ڈومین نام کی ضرورت ہے جسے آپ کنٹرول کرتے ہیں اور اس دستاویز کے ساتھ استعمال کرنا چاہتے ہیں۔

پروڈکشن کی تعیناتیوں میں، آپ کی ویب سائٹ میں ممکنہ طور پر آپ کے زیر انتظام مثال گروپ ورچوئل مشینوں (VMs) پر اس دستاویز میں دکھائے جانے سے کہیں زیادہ فائلیں اور اضافی ایپلیکیشن کوڈ شامل ہیں۔ کلاؤڈ اسٹوریج پھر ایک زیادہ محدود جامد ورژن کی میزبانی کرتا ہے جو کم سے کم فعالیت فراہم کرتا ہے۔ ایک گرم ناکامی کے منظر نامے میں، صارفین اس محدود ویب سائٹ کو اس وقت تک دیکھتے ہیں جب تک کہ منظم مثالی گروپس ٹھیک نہیں ہو جاتے اور ویب سائٹ کے مکمل تجربے کے لیے ٹریفک فراہم کر سکتے ہیں۔

اس ٹیوٹوریل میں، آپ مندرجہ ذیل تصویر میں دکھایا گیا ماحول بنانے کے لیے وسائل کی تعیناتی کرتے ہیں:
جب آپ کو ناکام ہونے کی ضرورت ہوتی ہے، تو آپ Cloud DNS کنفیگریشن کو اپ ڈیٹ کرتے ہیں تاکہ ٹریفک کو Cloud Storage کی طرف لے جایا جا سکے، جیسا کہ درج ذیل تصویر میں دکھایا گیا ہے:
یہ گرم فیل اوور پیٹرن کسی دوسرے علاقے میں کسی دوسرے منظم مثال کے گروپ کو چلانے کی لاگت کو متوازن کرتا ہے جسے آپ صرف اس وقت استعمال کرتے ہیں جب بنیادی علاقہ ناکام ہوجاتا ہے۔ کلاؤڈ سٹوریج کا استعمال کرتے ہوئے ایک جامد سائٹ کی لاگت دوسرے منظم مثال کے گروپ کو چلانے سے کم ہے، لیکن آپ کی میزبانی کے اختیارات کے درمیان کلاؤڈ DNS کو اپ ڈیٹ کرنے میں تھوڑی تاخیر ہوتی ہے۔ کلاؤڈ سٹوریج میں ویب سائٹ کا محدود تجربہ مکمل طور پر غیر دستیاب ویب سائٹ اور ناقص کسٹمر کے تجربے سے بہتر ہے۔

ایک متبادل نقطہ نظر کے لیے جو فیل اوور کو کنٹرول کرنے کے لیے کلاؤڈ DNS کے بجائے بیرونی HTTP(S) لوڈ بیلنسنگ کا استعمال کرتا ہے، Compute Engine اور Cloud Storage کے ساتھ ایک گرم قابل بازیافت ویب سرور تعینات کریں دیکھیں۔ یہ پیٹرن مفید ہے اگر آپ کے پاس کلاؤڈ DNS نہیں ہے، یا استعمال نہیں کرنا چاہتے

گوگل کلاؤڈ میں قابل بھروسہ ایپلی کیشنز چلانے کے لیے، ہم تجویز کرتے ہیں کہ آپ اپنے ایپلیکیشن کے انفراسٹرکچر کو بندش سے نمٹنے کے لیے ڈیزائن کریں۔ آپ کی درخواست اور کاروباری ضروریات پر منحصر ہے، آپ کو کولڈ فیل اوور، گرم فیل اوور، یا گرم فیل اوور پیٹرن کی ضرورت ہو سکتی ہے۔ اپنی درخواستوں کے لیے بہترین طریقہ کا تعین کرنے کے بارے میں مزید معلومات کے لیے، ڈیزاسٹر ریکوری پلاننگ گائیڈ دیکھیں

یہ دستاویز ایک بنیادی اپاچی ویب سرور کا استعمال کرتی ہے، لیکن بنیادی ڈھانچے کی تعیناتی کے لیے وہی نقطہ نظر دوسرے ایپلیکیشن ماحول پر لاگو ہوتا ہے جن کی آپ کو تخلیق کرنے کی ضرورت ہے۔

## مقاصد

- اپنی مرضی کے مطابق VM امیج کے ساتھ علاقائی منظم مثال کے گروپس بنائیں

- کلاؤڈ اسٹوریج بالٹی بنائیں

- کلاؤڈ DNS زون بنائیں اور کنفیگر کریں۔

- تازہ ترین کلاؤڈ DNS ریکارڈ کے ساتھ گرم ویب سرور فیل اوور کی جانچ کریں۔

- اپ ڈیٹ کردہ کلاؤڈ ڈی این ایس ریکارڈز کے ساتھ ریکوری اور فیل بیک کی جانچ کریں۔

## اخراجات
اس ٹیوٹوریل میں گوگل کلاؤڈ کے درج ذیل قابل بل اجزاء استعمال کیے گئے ہیں:
آپ کے متوقع استعمال کی بنیاد پر لاگت کا تخمینہ تیار کرنے کے لیے،
قیمت کا کیلکولیٹر استعمال کریں۔

## شروع کرنے سے پہلے
اگر آپ کی تنظیم آپ کے گوگل کلاؤڈ ماحول میں رکاوٹوں کا اطلاق کرتی ہے تو اس دستاویز کے کچھ اقدامات درست طریقے سے کام نہیں کرسکتے ہیں۔ اس صورت میں، ہو سکتا ہے آپ عوامی IP پتے یا سروس اکاؤنٹ کیز بنانے جیسے کاموں کو مکمل نہ کر سکیں۔ اگر آپ ایسی درخواست کرتے ہیں جو رکاوٹوں کے بارے میں ایک غلطی واپس کرتی ہے، تو دیکھیں کہ گوگل کلاؤڈ کے محدود ماحول میں ایپلیکیشنز کو کیسے تیار کیا جائے۔

- اپنے گوگل کلاؤڈ اکاؤنٹ میں سائن ان کریں۔ اگر آپ گوگل کلاؤڈ میں نئے ہیں تو اس بات کا اندازہ کرنے کے لیے ایک اکاؤنٹ بنائیں کہ حقیقی دنیا کے منظرناموں میں ہماری مصنوعات کیسی کارکردگی دکھاتی ہے۔ نئے صارفین کو کام کے بوجھ کو چلانے، جانچنے اور تعینات کرنے کے لیے $300 مفت کریڈٹس بھی ملتے ہیں۔

-
گوگل کلاؤڈ کنسول میں، پروجیکٹ سلیکٹر پیج پر، گوگل کلاؤڈ پروجیکٹ کو منتخب کریں یا تخلیق کریں۔

-
یقینی بنائیں کہ آپ کے کلاؤڈ پروجیکٹ کے لیے بلنگ فعال ہے۔ کسی پروجیکٹ پر بلنگ کو فعال کرنے کا طریقہ جانیں۔

-
کمپیوٹ انجن API کو فعال کریں۔

- گوگل کلاؤڈ CLI کو انسٹال اور شروع کریں۔

-
گوگل کلاؤڈ کنسول میں، پروجیکٹ سلیکٹر پیج پر، گوگل کلاؤڈ پروجیکٹ کو منتخب کریں یا تخلیق کریں۔

-
یقینی بنائیں کہ آپ کے کلاؤڈ پروجیکٹ کے لیے بلنگ فعال ہے۔ کسی پروجیکٹ پر بلنگ کو فعال کرنے کا طریقہ جانیں۔

-
کمپیوٹ انجن API کو فعال کریں۔

- گوگل کلاؤڈ CLI کو انسٹال اور شروع کریں۔

آپ گوگل کلاؤڈ سی ایل آئی کو انسٹال کیے بغیر گوگل کلاؤڈ کنسول میں گوگل کلاؤڈ CLI چلا سکتے ہیں۔ گوگل کلاؤڈ کنسول میں gcloud CLI چلانے کے لیے، کلاؤڈ شیل استعمال کریں۔

## ماحول کو تیار کریں۔
اس سیکشن میں، آپ اپنے وسائل کے ناموں اور مقامات کے لیے کچھ متغیرات کی وضاحت کرتے ہیں۔ یہ متغیرات گوگل کلاؤڈ CLI کمانڈز کے ذریعہ استعمال ہوتے ہیں جب آپ وسائل کو تعینات کرتے ہیں۔

اس پورے ٹیوٹوریل کے دوران، جب تک کہ دوسری صورت میں نوٹ نہ کیا جائے، آپ کلاؤڈ شیل یا اپنے مقامی ترقیاتی ماحول میں تمام کمانڈز درج کریں

بدل دیں۔
آپ کے اپنے پروجیکٹ ID کے ساتھ۔ اگر چاہیں تو وسائل کے لیے اپنے نام کا لاحقہ فراہم کریں تاکہ ان کی تلاش اور شناخت میں مدد ملے، جیسے
PROJECT_ID


ایپ
دو خطوں کی وضاحت کریں، جیسے
اور
us-west1
، اور ان علاقوں میں سے ایک کے اندر ایک زون، جیسے
us-west2
. یہ زون اس بات کی وضاحت کرتا ہے کہ ابتدائی بیس VM کہاں بنایا گیا ہے جو منظم مثال کے گروپ کے لیے تصویر بنانے کے لیے استعمال ہوتا ہے۔

us-west1-a
آخر میں، ایک ڈومین سیٹ کریں جو آپ کی جامد ویب سائٹ کے لیے استعمال ہو، جیسے
example.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## ایک VPC اور سب نیٹ بنائیں
VMs تک نیٹ ورک تک رسائی فراہم کرنے کے لیے، آپ ورچوئل پرائیویٹ کلاؤڈ (VPC) اور سب نیٹس بناتے ہیں۔ جیسا کہ آپ کو دو خطوں میں منظم مثال کے گروپس کی ضرورت ہے، آپ ہر علاقے میں ایک سب نیٹ بناتے ہیں۔ اپنے ماحول میں استعمال میں آئی پی ایڈریس کی حدود کو منظم کرنے کے لیے کسٹم سب نیٹ موڈ کے فوائد کے بارے میں مزید معلومات کے لیے، کسٹم موڈ VPC نیٹ ورک استعمال کریں دیکھیں

اپنی مرضی کے سب نیٹ موڈ کے ساتھ VPC بنائیں:
gcloud کمپیوٹ نیٹ ورک نیٹ ورک بناتے ہیں-$NAME_SUFFIX --subnet-mode=custom
اب نئے VPC میں دو ذیلی نیٹ بنائیں، ہر علاقے کے لیے ایک۔ اپنے اپنے ایڈریس رینجز کی وضاحت کریں، جیسے
اور
10.1.0.0/20
، جو آپ کے نیٹ ورک کی حد میں فٹ ہے:
10.2.0.0/20
gcloud کمپیوٹ نیٹ ورکس ذیلی نیٹ تخلیق کرتا ہے \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 gcloud کمپیوٹ نیٹ ورکس ذیلی نیٹ تخلیق کرتا ہے \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ علاقہ 2
## فائر وال رولز بنائیں
VPC میں نیٹ ورک ٹریفک کو صحیح طریقے سے چلنے دینے کے لیے، فائر وال کے اصول استعمال کریں۔

لوڈ بیلنس اور منظم مثالی گروپس کے لیے ویب ٹریفک اور صحت کی جانچ کی اجازت دینے کے لیے فائر وال کے اصول بنائیں:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ -- source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ - -direction=ingress\ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check\ --rules=tcp:80
HTTP اصول کسی بھی VM پر ٹریفک کی اجازت دیتا ہے جہاں
HTTP-servertag لاگو کیا جاتا ہے، اور کسی بھی ذریعہ سے
0.0.0.0/0رینج صحت کی جانچ کے اصول کے لیے، گوگل کلاؤڈ کے لیے پہلے سے طے شدہ رینجز پلیٹ فارم کو وسائل کی صحت کو درست طریقے سے جانچنے کی اجازت دینے کے لیے سیٹ کی گئی ہیں۔

بیس VM امیج کی ابتدائی ترتیب کے لیے SSH ٹریفک کی اجازت دینے کے لیے، فائر وال کے اصول کو اپنے ماحول میں استعمال کرتے ہوئے
--source-range پیرامیٹر۔ آپ کو اپنی نیٹ ورک ٹیم کے ساتھ کام کرنے کی ضرورت پڑ سکتی ہے تاکہ یہ تعین کیا جا سکے کہ آپ کی تنظیم کون سے ماخذ کی حدود استعمال کرتی ہے۔

بدل دیں۔
آپ کے اپنے IP ایڈریس کے دائرہ کار کے ساتھ:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- source-ranges=
IP_ADDRESS_SCOPE
 فائر وال رولز بنانے کے بعد، تصدیق کریں کہ تین اصول شامل کیے گئے ہیں:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"مندرجہ ذیل مثال کے آؤٹ پٹ سے پتہ چلتا ہے کہ تین اصول صحیح طریقے سے بنائے گئے ہیں:
NAME نیٹ ورک کی سمت کی ترجیح اجازت دیں-صحت-چیک-ایپ نیٹ ورک-ایپ انگریز 1000 tcp:80 اجازت دیں-http-app نیٹ ورک-ایپ انگریز 1000 tcp:80 اجازت دیں-ssh-app نیٹ ورک-ایپ انگریز 1000 tcp:22
## بیس VM امیج بنائیں اور کنفیگر کریں۔
ایک جیسی VMs بنانے کے لیے جنہیں آپ اضافی کنفیگریشن کے بغیر تعینات کرتے ہیں، آپ ایک حسب ضرورت VM امیج استعمال کرتے ہیں۔ یہ تصویر OS اور Apache کنفیگریشن کو کیپچر کرتی ہے، اور اگلے مراحل میں منظم مثال کے گروپ میں ہر VM بنانے کے لیے استعمال ہوتی ہے۔

VM پر، آپ ایک بنیادی بناتے ہیں۔
مستقل ڈسک پر index.html فائل اور
اس پر چڑھائیں
/var/www/example.com۔ پر ایک اپاچی کنفیگریشن فائل
/etc/apache2/sites-available/example.com.conf سے ویب مواد پیش کرتا ہے
لگاتار ڈسک کا مقام نصب

مندرجہ ذیل خاکہ اپاچی کے ذریعہ پیش کردہ بنیادی HTML صفحہ کو دکھاتا ہے جو مستقل ڈسک پر محفوظ ہے:
آپ اس ماحول کو درج ذیل مراحل میں بناتے ہیں۔

منسلک مستقل ڈسک کے ساتھ بیس VM بنائیں:
gcloud کمپیوٹ مثالوں سے vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ --image=debian-10-buster-v20210420 \ --image-project=debian-Cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk- device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
آپ VM کو نام دینے اور صحیح سب نیٹ سے جڑنے کے لیے اس دستاویز کے شروع میں بیان کردہ پیرامیٹرز استعمال کرتے ہیں۔ بوٹ ڈسک اور ڈیٹا ڈسک کے لیے پیرامیٹرز سے نام بھی تفویض کیے گئے ہیں۔

سادہ ویب سائٹ کو انسٹال اور کنفیگر کرنے کے لیے، پہلے SSH کا استعمال کرتے ہوئے بیس VM سے جڑیں:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
VM پر اپنے SSH سیشن میں، VM کو اپنی پسند کے ایڈیٹر میں کنفیگر کرنے کے لیے ایک اسکرپٹ بنائیں۔ درج ذیل مثال نینو کو بطور ایڈیٹر استعمال کرتی ہے۔
nano configure-vm.
فائل میں درج ذیل کنفیگریشن اسکرپٹ کو چسپاں کریں:
bin/bash NAME_SUFFIX=
app# بنیادی ویب سائٹ فائلوں کے لیے ڈائرکٹری بنائیں sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # ڈسک کا نام تلاش کریں، پھر فارمیٹ کریں اور اسے DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATH تلاش کریں /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,Discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # اپاچی سوڈو اپ ڈیٹ انسٹال کریں&&  sudo apt-get -y install apache2 # پرسسٹنٹ ڈسک پر ایک بنیادی HTML فائل لکھیں sudo tee -a /var/www/example.com/index.html >/dev/null EOF'    HA / DR مثال   
 Cloud Storagep>پر گرم فیل اوور کے ساتھ کمپیوٹ انجن ویب سائٹ میں خوش آمدید
*:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/example.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined  EOF # اپاچی کنفیگریشن فائل کو فعال کریں اور سروس کو دوبارہ لوڈ کریں sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
اپ ڈیٹ کریں۔
اس دستاویز کے شروع میں سیٹ کی گئی قدر سے ملنے کے لیے متغیر، جیسے
NAME_SUFFIX ایپ

فائل کو لکھیں اور اپنے ایڈیٹر سے باہر نکلیں۔ مثال کے طور پر، نینو میں آپ استعمال کرتے ہیں۔
Ctrl-Oto فائل کو لکھیں، پھر باہر نکلیں۔
Ctrl-X

کنفیگریشن اسکرپٹ کو قابل عمل بنائیں، پھر اسے چلائیں:
chmod +x configure-vm../configure-vm۔
SSH سیشن سے باہر نکلیں VM پر:
باہر نکلیں
VM کا IP ایڈریس حاصل کریں اور استعمال کریں۔
بنیادی ویب صفحہ دیکھنے کے لیے curl:
curl $(gcloud compute مثالیں بیان کرتی ہیں vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
بنیادی ویب سائٹ واپس آ گئی ہے، جیسا کہ درج ذیل مثال کے آؤٹ پٹ میں دکھایا گیا ہے:
    HA / DR مثال   
 Cloud Storagep>پر گرم فیل اوور کے ساتھ کمپیوٹ انجن ویب سائٹ میں خوش آمدید

# بیس VM امیجز بنائیں gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute images create image-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX\ --source-disk-zone=$ZONE # مثال کے سانچے بنائیں gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard- 1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount \ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server\ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # VM مثالوں کے لیے ہیلتھ چیک بنائیں \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups منظم instance-group بنائیں -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## لوڈ بیلنسر بنائیں اور کنفیگر کریں۔
صارفین کے لیے آپ کی ویب سائٹ تک رسائی حاصل کرنے کے لیے، آپ کو VMs تک ٹریفک کی اجازت دینی ہوگی جو منظم مثالی گروپس میں چلتے ہیں۔ اگر کسی منظم مثال کے گروپ میں زون کی ناکامی ہو تو آپ خود بخود ٹریفک کو نئے VMs پر ری ڈائریکٹ کرنا چاہتے ہیں۔

درج ذیل سیکشن میں، آپ پورٹ 80 پر HTTP ٹریفک کے لیے بیک اینڈ سروس کے ساتھ ایک بیرونی HTTPS لوڈ بیلنس بناتے ہیں، پچھلے مراحل میں بنائے گئے ہیلتھ چیک کا استعمال کرتے ہیں، اور بیک اینڈ سروس کے ذریعے ایک بیرونی IP ایڈریس کا نقشہ بناتے ہیں۔

مزید معلومات کے لیے، ایک سادہ بیرونی HTTP لوڈ بیلنسر سیٹ اپ کرنے کا طریقہ دیکھیں

اپنی درخواست کے لیے لوڈ بیلنسر بنائیں اور کنفیگر کریں:
# HTTP پورٹ 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set- کے لیے پورٹ رولز ترتیب دیں name-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # بیک اینڈ سروس بنائیں اور اس میں منظم مثال کے گروپس کو شامل کریں gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # بیک اینڈ سروس کے لیے URL کا نقشہ بنائیں gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # HTTP ٹریفک کے لیے فارورڈنگ کو ترتیب دیں gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute forwarding-rules create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
ویب ٹریفک کے لیے فارورڈنگ اصول کا IP پتہ حاصل کریں:
IP_ADDRESSgcloud کمپیوٹ فارورڈنگ کے اصول http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress) کی وضاحت کرتے ہیں
استعمال کریں۔
پچھلے مرحلے سے لوڈ بیلنسر کے آئی پی ایڈریس کا استعمال کرتے ہوئے ویب سائٹ دیکھنے کے لیے curl، یا اپنا ویب براؤزر کھولیں:
curl $IP_ADDRESS
 لوڈ بیلنسر کو تعیناتی مکمل کرنے اور ٹریفک کو صحیح طریقے سے آپ کے بیک اینڈ پر بھیجنے میں چند منٹ لگتے ہیں۔ ایک HTTP 404 خرابی واپس آ جاتی ہے اگر لوڈ بیلنسر ابھی بھی تعینات ہو رہا ہے۔ اگر ضرورت ہو تو، چند منٹ انتظار کریں اور دوبارہ ویب سائٹ تک رسائی حاصل کرنے کی کوشش کریں۔

بنیادی ویب سائٹ واپس آ گئی ہے، جیسا کہ درج ذیل مثال کے آؤٹ پٹ میں دکھایا گیا ہے:
    HA / DR مثال   
 Cloud Storagep>پر گرم فیل اوور کے ساتھ کمپیوٹ انجن ویب سائٹ میں خوش آمدید
< index.html     HA / DR example   
Welcome to a test static web server with warm failover from Cloud Storagep> 

example.com
Get the details of the Cloud DNS zone:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step

For more information and an example using Google Domains, see How to update name servers

In your Cloud DNS zone, add a record for
wwwusing the load balancer IP address obtained in a previous section:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user

Create a record to be used by the Cloud Storage bucket for the static website:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
This example uses
static-webas the subdomain. Leave the
c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user
Finally,the DNS record additions to the zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
## Verify and test the DNS zone and records
Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image:
- Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs

- A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups

- The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket

To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions

Get the details of the Cloud DNS zone again:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

To resolve the
wwwrecord for your Cloud DNS zone against one of these name servers, use the
digcommand:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
This example uses the
ns-cloud-b1.googledomains.comnameserver address returned from the previous
describecommand. Provide your own nameserver address shown in the output of the previous command
The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using
curland the
--resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer

;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Use the
digcommand again to verify the DNS record for the static website in Cloud Storage:
dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket:
;DiG [email protected] static-web.example.com ; (1 server found);; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail over to the Cloud Storage bucket
In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups

When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image:
When you or your monitoring solution determine the most appropriate action

is to update the Cloud DNS records to direct traffic to Cloud Storage,
update the existing DNS
A record. In this document, you manually update the
Cloud DNS records to redirect traffic to the Cloud Storage-hosted
static website

To fail over the Cloud DNS records, remove the existing
Arecord that resolves to the load balancer:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Create a
CNAMErecord for
wwwthat points to the Cloud Storage-hosted content:
gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand to confirm the
wwwrecord now resolves to the address of the Cloud Storage static website:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the
www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access
www.example.comare redirected to the Cloud Storage bucket, which displays the static website:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail back to the managed instance groups
After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records

When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image:
Remove the
wwwCNAME record that redirects traffic to the Cloud Storage-hosted content:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Add an
Arecord to point to the load balancer in front of the managed instance groups again:

gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand one more time to confirm the
wwwrecord resolves to the address of the load balancer in front of the managed instance groups again:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
## Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources

To delete the individual resources created in this document, complete the following steps:
Delete the DNS zone and records:
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIX
Delete the Cloud Storage bucket:
gsutil rm -r gsstatic-web.$DOMAIN
Delete the load balancer configuration:
gcloud compute forwarding-rules delete \ http-content-rule-$NAME_SUFFIX --global --quiet gcloud compute target-http-proxies delete \ http-lb-proxy-$NAME_SUFFIX --quiet gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet
Delete the managed instance groups and health check:
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Delete the instance templates, images, base VM, and persistent disks:
gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION2 --quiet gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute images delete image-disk-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX \ --zone=$ZONE --quiet
Delete the firewall rules


gcloud compute firewall-rules delete \ allow-health-check-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-ssh-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-http-$NAME_SUFFIX --quiet
Delete the subnet and VPC

gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
## What's next
- For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't want to use, Cloud DNS

- To learn how how to determine the best approach for your own applications and which recovery method to use, see the Disaster recovery planning guide

- To see other patterns for applications, such as cold and hot failover, see Disaster recovery scenarios for applications

- For more ways to handle scale and availability, see the Patterns for scalable and resilient apps

- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.