VMware vSphere کے ساتھ کام کرتے وقت AFA AccelStor کو ترتیب دینے کی سفارشات

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

AccelStor NeoSapphire™ تمام فلیش ارے ہیں۔ ایک بات یا двух SSD ڈرائیوز پر مبنی نوڈ ڈیوائسز ڈیٹا اسٹوریج کے تصور کو نافذ کرنے اور ملکیتی ٹیکنالوجی کا استعمال کرتے ہوئے اس تک رسائی کو منظم کرنے کے لیے بنیادی طور پر مختلف نقطہ نظر کے ساتھ FlexiRemap® بہت مشہور RAID الگورتھم کے بجائے۔ صفیں میزبانوں کو فائبر چینل یا iSCSI انٹرفیس کے ذریعے بلاک رسائی فراہم کرتی ہیں۔ منصفانہ ہونے کے لیے، ہم نوٹ کرتے ہیں کہ ISCSI انٹرفیس والے ماڈلز کو بھی ایک اچھا بونس کے طور پر فائل تک رسائی حاصل ہوتی ہے۔ لیکن اس مضمون میں ہم بلاک پروٹوکول کے استعمال پر توجہ مرکوز کریں گے جیسا کہ آل فلیش کے لیے سب سے زیادہ کارآمد ہے۔

AccelStor سرنی اور VMware vSphere ورچوئلائزیشن سسٹم کے مشترکہ آپریشن کی تعیناتی اور بعد میں ترتیب کے پورے عمل کو کئی مراحل میں تقسیم کیا جا سکتا ہے:

• کنکشن ٹوپولوجی کا نفاذ اور SAN نیٹ ورک کی تشکیل؛
• تمام فلیش سرنی کو ترتیب دینا؛
• ESXi میزبانوں کو ترتیب دینا؛
• ورچوئل مشینیں ترتیب دینا۔

AccelStor NeoSapphire™ Fiber Channel arrays اور iSCSI arrays کو بطور نمونہ ہارڈ ویئر استعمال کیا گیا تھا۔ بنیادی سافٹ ویئر VMware vSphere 6.7U1 ہے۔

اس مضمون میں بیان کردہ سسٹمز کو تعینات کرنے سے پہلے، یہ انتہائی سفارش کی جاتی ہے کہ آپ VMware سے کارکردگی کے مسائل سے متعلق دستاویزات کو پڑھیں (VMware vSphere 6.7 کے لیے کارکردگی کے بہترین طریقے ) اور iSCSI ترتیبات (iSCSI پر VMware vSphere چلانے کے بہترین طریقے)

کنکشن ٹوپولوجی اور SAN نیٹ ورک کنفیگریشن

SAN نیٹ ورک کے اہم اجزاء ESXi میزبانوں میں HBAs، SAN سوئچز اور ارے نوڈس ہیں۔ اس طرح کے نیٹ ورک کے لئے ایک عام ٹوپولوجی اس طرح نظر آئے گی:

یہاں پر سوئچ کی اصطلاح سے مراد ایک الگ فزیکل سوئچ یا سوئچز کا سیٹ (فیبرک) اور مختلف سروسز کے درمیان مشترکہ ڈیوائس (فائبر چینل کے معاملے میں VSAN اور iSCSI کی صورت میں VLAN) دونوں سے مراد ہے۔ دو آزاد سوئچز/فیبرکس کا استعمال ناکامی کے ممکنہ نقطہ کو ختم کر دے گا۔

میزبانوں کا سرنی سے براہ راست رابطہ، اگرچہ تعاون یافتہ ہے، انتہائی سفارش نہیں کی جاتی ہے۔ All Flash arrays کی کارکردگی کافی زیادہ ہے۔ اور زیادہ سے زیادہ رفتار کے لیے، صف کی تمام بندرگاہوں کو استعمال کرنا چاہیے۔ لہذا، میزبانوں اور NeoSapphire™ کے درمیان کم از کم ایک سوئچ کی موجودگی لازمی ہے۔

میزبان HBA پر دو بندرگاہوں کی موجودگی بھی زیادہ سے زیادہ کارکردگی کو حاصل کرنے اور غلطی کی برداشت کو یقینی بنانے کے لیے ایک لازمی شرط ہے۔

فائبر چینل انٹرفیس کا استعمال کرتے وقت، شروع کرنے والوں اور اہداف کے درمیان ممکنہ تصادم کو ختم کرنے کے لیے زوننگ کو ترتیب دیا جانا چاہیے۔ زونز "ایک انیشی ایٹر پورٹ - ایک یا زیادہ اری پورٹس" کے اصول پر بنائے گئے ہیں۔

اگر آپ دوسری سروسز کے ساتھ اشتراک کردہ سوئچ استعمال کرنے کی صورت میں iSCSI کے ذریعے کنکشن استعمال کرتے ہیں، تو یہ ضروری ہے کہ iSCSI ٹریفک کو علیحدہ VLAN کے اندر الگ کیا جائے۔ جمبو فریمز (MTU = 9000) کے لیے سپورٹ کو فعال کرنے کی بھی انتہائی سفارش کی جاتی ہے تاکہ نیٹ ورک پر پیکٹس کا سائز بڑھایا جا سکے اور اس طرح ٹرانسمیشن کے دوران اوور ہیڈ معلومات کی مقدار کو کم کیا جا سکے۔ تاہم، یہ یاد رکھنے کے قابل ہے کہ درست آپریشن کے لیے "انیشی ایٹر-سوئچ-ٹارگٹ" چین کے ساتھ نیٹ ورک کے تمام اجزاء پر MTU پیرامیٹر کو تبدیل کرنا ضروری ہے۔

تمام فلیش سرنی ترتیب دے رہا ہے۔

صف پہلے سے تشکیل شدہ گروپس والے صارفین کو پہنچائی جاتی ہے۔ FlexiRemap®. لہذا، ڈرائیوز کو ایک ہی ڈھانچے میں جوڑنے کے لیے کوئی اقدامات کرنے کی ضرورت نہیں ہے۔ آپ کو صرف مطلوبہ سائز اور مقدار کے حجم بنانے کی ضرورت ہے۔

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

اس کے بعد، تخلیق شدہ جلدوں کو "شائع" کرنا اور ACLs (iSCSI کے لیے IP پتے اور FC کے لیے WWPN) کا استعمال کرتے ہوئے میزبانوں سے ان تک رسائی کے حقوق متعین کرنا اور ارے پورٹس کے ذریعے جسمانی علیحدگی باقی ہے۔ iSCSI ماڈلز کے لیے یہ ایک ہدف بنا کر کیا جاتا ہے۔

FC ماڈلز کے لیے، اشاعت صف کے ہر پورٹ کے لیے LUN کی تخلیق کے ذریعے ہوتی ہے۔

سیٹ اپ کے عمل کو تیز کرنے کے لیے، میزبانوں کو گروپس میں ملایا جا سکتا ہے۔ مزید برآں، اگر میزبان ملٹی پورٹ FC HBA استعمال کرتا ہے (جو عملی طور پر اکثر ہوتا ہے)، تو سسٹم خود بخود اس بات کا تعین کرتا ہے کہ اس طرح کے HBA کی بندرگاہیں WWPNs کی بدولت ایک ہی میزبان سے تعلق رکھتی ہیں جو ایک دوسرے سے مختلف ہوتی ہیں۔ ہدف/LUN کی بیچ تخلیق دونوں انٹرفیس کے لیے بھی معاون ہے۔

iSCSI انٹرفیس کا استعمال کرتے وقت ایک اہم نوٹ کارکردگی کو بڑھانے کے لیے حجم کے لیے ایک ہی وقت میں متعدد اہداف بنانا ہے، کیونکہ ہدف پر قطار کو تبدیل نہیں کیا جا سکتا اور مؤثر طریقے سے ایک رکاوٹ ہو گی۔

ESXi میزبانوں کو ترتیب دینا

ESXi میزبان کی طرف، بنیادی ترتیب مکمل طور پر متوقع منظر نامے کے مطابق کی جاتی ہے۔ iSCSI کنکشن کا طریقہ کار:

1. سافٹ ویئر iSCSI اڈاپٹر شامل کریں (ضرورت نہیں ہے اگر یہ پہلے ہی شامل کیا گیا ہے، یا اگر آپ ہارڈ ویئر iSCSI اڈاپٹر استعمال کر رہے ہیں)؛
2. ایک vSwitch بنانا جس کے ذریعے iSCSI ٹریفک گزرے گا، اور اس میں ایک فزیکل اپلنک اور VMkernal شامل کرنا؛
3. Dynamic Discovery میں صف کے پتے شامل کرنا؛
4. ڈیٹا اسٹور کی تخلیق

کچھ اہم نوٹ:

• عام صورت میں، یقیناً، آپ ایک موجودہ vSwitch استعمال کر سکتے ہیں، لیکن ایک علیحدہ vSwitch کی صورت میں، میزبان کی ترتیبات کو سنبھالنا بہت آسان ہو جائے گا۔
• کارکردگی کے مسائل سے بچنے کے لیے مینجمنٹ اور iSCSI ٹریفک کو الگ الگ فزیکل لنکس اور/یا VLANs پر الگ کرنا ضروری ہے۔
• VMkernal کے IP پتے اور آل فلیش اری کے متعلقہ پورٹس ایک ہی سب نیٹ کے اندر ہونے چاہئیں، دوبارہ کارکردگی کے مسائل کی وجہ سے۔
• VMware کے اصولوں کے مطابق غلطی کی برداشت کو یقینی بنانے کے لیے، vSwitch میں کم از کم دو فزیکل اپ لنکس ہونے چاہئیں
• اگر جمبو فریم استعمال کیے جاتے ہیں، تو آپ کو vSwitch اور VMkernal دونوں کے MTU کو تبدیل کرنے کی ضرورت ہے۔
• آپ کو یاد دلانا مفید ہوگا کہ جسمانی اڈاپٹر کے لیے VMware کی سفارشات کے مطابق جو iSCSI ٹریفک کے ساتھ کام کرنے کے لیے استعمال کیے جائیں گے، ٹیمنگ اور فیل اوور کو کنفیگر کرنا ضروری ہے۔ خاص طور پر، ہر VMkernal کو صرف ایک اپلنک کے ذریعے کام کرنا چاہیے، دوسرے اپلنک کو غیر استعمال شدہ موڈ میں تبدیل کرنا چاہیے۔ غلطی کو برداشت کرنے کے لیے، آپ کو دو VMkernals شامل کرنے ہوں گے، جن میں سے ہر ایک اپنے اپلنک کے ذریعے کام کرے گا۔

VMkernel اڈاپٹر (vmk#)
فزیکل نیٹ ورک اڈاپٹر (vmnic#)

vmk1 (اسٹوریج01)
ایکٹو اڈاپٹر
vmnic2
غیر استعمال شدہ اڈاپٹر
vmnic3

vmk2 (اسٹوریج02)
ایکٹو اڈاپٹر
vmnic3
غیر استعمال شدہ اڈاپٹر
vmnic2

فائبر چینل کے ذریعے جڑنے کے لیے کسی ابتدائی اقدامات کی ضرورت نہیں ہے۔ آپ فوری طور پر ڈیٹا اسٹور بنا سکتے ہیں۔

ڈیٹا اسٹور بنانے کے بعد، آپ کو یہ یقینی بنانا ہوگا کہ ٹارگٹ/LUN کے راستوں کے لیے راؤنڈ رابن پالیسی سب سے زیادہ پرفارمنس کے طور پر استعمال ہوتی ہے۔

پہلے سے طے شدہ طور پر، VMware کی ترتیبات اسکیم کے مطابق اس پالیسی کے استعمال کے لیے فراہم کرتی ہیں: 1000 درخواستیں پہلے راستے سے، اگلی 1000 درخواستیں دوسرے راستے سے، وغیرہ۔ میزبان اور دو کنٹرولر سرنی کے درمیان اس طرح کا تعامل غیر متوازن ہوگا۔ لہذا، ہم راؤنڈ رابن پالیسی = 1 پیرامیٹر Esxcli/PowerCLI کے ذریعے ترتیب دینے کی تجویز کرتے ہیں۔

پیرامیٹر

Esxcli کے لیے:

• دستیاب LUNs کی فہرست بنائیں

esxcli اسٹوریج این ایم پی ڈیوائس کی فہرست

• ڈیوائس کا نام کاپی کریں۔
• راؤنڈ رابن پالیسی تبدیل کریں۔

esxcli سٹوریج nmp psp راؤنڈروبن ڈیوائس کنفگ سیٹ —type=iops —iops=1 —device=“Device_ID”

زیادہ تر جدید ایپلی کیشنز کو بڑے ڈیٹا پیکٹ کے تبادلے کے لیے ڈیزائن کیا گیا ہے تاکہ بینڈوتھ کے استعمال کو زیادہ سے زیادہ کیا جا سکے اور CPU لوڈ کو کم کیا جا سکے۔ لہذا، ESXi بذریعہ ڈیفالٹ 32767KB تک کے ٹکڑوں میں اسٹوریج ڈیوائس کے لیے I/O کی درخواستیں جاری کرتا ہے۔ تاہم، کچھ منظرناموں کے لیے، چھوٹے ٹکڑوں کا تبادلہ زیادہ نتیجہ خیز ہوگا۔ AccelStor arrays کے لیے، یہ درج ذیل منظرنامے ہیں:

• ورچوئل مشین Legacy BIOS کے بجائے UEFI استعمال کرتی ہے۔
• vSphere نقل استعمال کرتا ہے۔

ایسے حالات کے لیے، Disk.DiskMaxIOSize پیرامیٹر کی قدر کو 4096 میں تبدیل کرنے کی سفارش کی جاتی ہے۔

iSCSI کنکشنز کے لیے، کنکشن کے استحکام کو بڑھانے کے لیے لاگ ان ٹائم آؤٹ پیرامیٹر کو 30 (پہلے سے طے شدہ 5) میں تبدیل کرنے کی سفارش کی جاتی ہے اور آگے بھیجے گئے پیکٹوں کی تصدیق کے لیے DelayedAck تاخیر کو غیر فعال کریں۔ دونوں اختیارات vSphere کلائنٹ میں ہیں: میزبان → کنفیگر → اسٹوریج → اسٹوریج اڈاپٹر → ایڈوانسڈ آپشنز برائے iSCSI اڈاپٹر

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

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

ورچوئل مشینیں ترتیب دینا

ورچوئل مشینیں ترتیب دیتے وقت کوئی خاص تقاضے نہیں ہیں، یا اس کے بجائے وہ کافی عام ہیں:

• سب سے زیادہ ممکنہ VM ورژن استعمال کرنا (مطابقت)
• ورچوئل مشینوں کو گھنے لگاتے وقت ریم کا سائز سیٹ کرنے میں زیادہ احتیاط برتی جاتی ہے، مثال کے طور پر، VDI میں (چونکہ پہلے سے طے شدہ طور پر، سٹارٹ اپ کے وقت، RAM کے مطابق سائز کی ایک صفحہ فائل بنائی جاتی ہے، جو مفید صلاحیت استعمال کرتی ہے اور اس کا اثر ہوتا ہے۔ آخری کارکردگی)
• IO کے لحاظ سے سب سے زیادہ پیداواری اڈاپٹر ورژن استعمال کریں: نیٹ ورک کی قسم VMXNET 3 اور SCSI قسم PVSCSI
• زیادہ سے زیادہ کارکردگی کے لیے Thin Provision Eager Zeroed ڈسک کی قسم اور زیادہ سے زیادہ اسٹوریج کی جگہ کے استعمال کے لیے پتلی پروویژننگ کا استعمال کریں
• اگر ممکن ہو تو، ورچوئل ڈسک کی حد کا استعمال کرتے ہوئے غیر I/O اہم مشینوں کے آپریشن کو محدود کریں۔
• VMware ٹولز کو انسٹال کرنا یقینی بنائیں

قطاروں پر نوٹس

قطار (یا بقایا I/Os) ان پٹ/آؤٹ پٹ درخواستوں (SCSI کمانڈز) کی تعداد ہے جو کسی مخصوص ڈیوائس/ایپلی کیشن کے لیے کسی بھی وقت پروسیسنگ کا انتظار کر رہی ہیں۔ قطار کے اوور فلو کی صورت میں، QFULL غلطیاں جاری کی جاتی ہیں، جس کے نتیجے میں لیٹنسی پیرامیٹر میں اضافہ ہوتا ہے۔ ڈسک (سپنڈل) اسٹوریج سسٹم کا استعمال کرتے وقت، نظریاتی طور پر، قطار جتنی زیادہ ہوگی، ان کی کارکردگی اتنی ہی زیادہ ہوگی۔ تاہم، آپ کو اس کا غلط استعمال نہیں کرنا چاہیے، کیونکہ QFULL میں جانا آسان ہے۔ تمام فلیش سسٹمز کے معاملے میں، ایک طرف، سب کچھ کچھ آسان ہے: سب کے بعد، صف میں تاخیر ہوتی ہے جو کہ کم شدت کے آرڈر ہوتے ہیں اور اس لیے، اکثر اوقات، قطاروں کے سائز کو الگ سے ریگولیٹ کرنے کی ضرورت نہیں ہوتی ہے۔ لیکن دوسری طرف، کچھ استعمال کے منظرناموں میں (مخصوص ورچوئل مشینوں کے لیے IO کی ضروریات میں مضبوط ترچھی، زیادہ سے زیادہ کارکردگی کے لیے ٹیسٹ وغیرہ) یہ ضروری ہے، اگر قطاروں کے پیرامیٹرز کو تبدیل نہ کیا جائے، تو کم از کم یہ سمجھنا چاہیے کہ کیا اشارے ہیں۔ حاصل کیا جا سکتا ہے، اور، اہم بات یہ ہے کہ کن طریقوں سے۔

AccelStor آل فلیش ارے پر ہی حجم یا I/O پورٹس کے سلسلے میں کوئی حد نہیں ہے۔ اگر ضروری ہو تو، ایک حجم بھی صف کے تمام وسائل حاصل کرسکتا ہے۔ قطار کی واحد حد iSCSI اہداف کے لیے ہے۔ یہی وجہ ہے کہ اس حد پر قابو پانے کے لیے ہر حجم کے لیے کئی (مثالی طور پر 8 ٹکڑوں تک) اہداف بنانے کی ضرورت کا اوپر اشارہ کیا گیا تھا۔ آئیے یہ بھی دہرائیں کہ AccelStor arrays بہت نتیجہ خیز حل ہیں۔ لہذا، آپ کو زیادہ سے زیادہ رفتار حاصل کرنے کے لیے سسٹم کے تمام انٹرفیس پورٹس کا استعمال کرنا چاہیے۔

ESXi کے میزبان کی طرف، صورتحال بالکل مختلف ہے۔ میزبان خود تمام شرکاء کے لیے وسائل تک مساوی رسائی کی مشق کا اطلاق کرتا ہے۔ لہذا، مہمان OS اور HBA کے لیے الگ الگ IO قطاریں ہیں۔ مہمان OS کی قطاروں کو قطاروں سے ورچوئل SCSI اڈاپٹر اور ورچوئل ڈسک تک جوڑ دیا جاتا ہے:

HBA کی قطار مخصوص قسم/وینڈر پر منحصر ہے:

ورچوئل مشین کی حتمی کارکردگی کا تعین میزبان اجزاء کے درمیان سب سے کم قطار کی گہرائی کی حد سے کیا جائے گا۔

ان اقدار کی بدولت، ہم کارکردگی کے ان اشاریوں کا اندازہ لگا سکتے ہیں جو ہم کسی خاص ترتیب میں حاصل کر سکتے ہیں۔ مثال کے طور پر، ہم 0.5ms کی تاخیر کے ساتھ ایک ورچوئل مشین (بلاک بائنڈنگ کے بغیر) کی نظریاتی کارکردگی جاننا چاہتے ہیں۔ پھر اس کا IOPS = (1,000/لیٹنسی) * بقایا I/Os (قطار کی گہرائی کی حد)

مثالیں

مثال کے طور پر 1

• ایف سی ایمولیکس ایچ بی اے اڈاپٹر
• ایک VM فی ڈیٹا اسٹور
• VMware Paravirtual SCSI اڈاپٹر

یہاں قطار کی گہرائی کی حد Emulex HBA کے ذریعے طے کی جاتی ہے۔ لہذا IOPS = (1000/0.5)*32 = 64K

مثال کے طور پر 2

• VMware iSCSI سافٹ ویئر اڈاپٹر
• ایک VM فی ڈیٹا اسٹور
• VMware Paravirtual SCSI اڈاپٹر

یہاں قطار کی گہرائی کی حد پہلے ہی Paravirtual SCSI اڈاپٹر کے ذریعے طے کی گئی ہے۔ لہذا IOPS = (1000/0.5)*64 = 128K

تمام فلیش AccelStor صفوں کے ٹاپ ماڈلز (مثال کے طور پر، P710) 700K بلاک پر 4K IOPS تحریری کارکردگی فراہم کرنے کے قابل ہیں۔ اس طرح کے بلاک سائز کے ساتھ، یہ بالکل واضح ہے کہ ایک واحد ورچوئل مشین اس طرح کی صف کو لوڈ کرنے کے قابل نہیں ہے۔ ایسا کرنے کے لیے، آپ کو 11 (مثال کے طور پر 1) یا 6 (مثال کے طور پر 2) ورچوئل مشینوں کی ضرورت ہوگی۔

نتیجے کے طور پر، ورچوئل ڈیٹا سینٹر کے تمام بیان کردہ اجزاء کی درست ترتیب کے ساتھ، آپ کارکردگی کے لحاظ سے بہت متاثر کن نتائج حاصل کر سکتے ہیں۔

4K رینڈم، 70% پڑھنا/30% لکھنا

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

ماخذ: www.habr.com