کسٹمر VDI چاہتا تھا۔ میں نے واقعی SimpliVity + VDI Citrix ورچوئل ڈیسک ٹاپ مجموعہ کو دیکھا۔ تمام آپریٹرز، سٹی آفس ملازمین وغیرہ کے لیے۔ صرف ہجرت کی پہلی لہر میں پانچ ہزار صارفین ہیں، اور اس لیے انہوں نے لوڈ ٹیسٹنگ پر اصرار کیا۔ VDI سست ہونا شروع کر سکتا ہے، یہ سکون سے لیٹ سکتا ہے - اور یہ ہمیشہ چینل کے ساتھ مسائل کی وجہ سے نہیں ہوتا ہے۔ ہم نے خاص طور پر VDI کے لیے ایک بہت طاقتور ٹیسٹنگ پیکج خریدا اور بنیادی ڈھانچے کو اس وقت تک لوڈ کیا جب تک کہ یہ ڈسک اور پروسیسر پر بہت زیادہ بھاری نہ ہو۔
لہذا، ہمیں جدید ترین VDI ٹیسٹوں کے لیے پلاسٹک کی بوتل اور LoginVSI سافٹ ویئر کی ضرورت ہوگی۔ ہمارے پاس یہ 300 صارفین کے لیے لائسنس کے ساتھ ہے۔ پھر ہم نے HPE SimpliVity 380 ہارڈویئر کو ایک پیکج میں لیا جو فی سرور زیادہ سے زیادہ صارف کثافت کے کام کے لیے موزوں تھا، اچھی اوور سبسکرپشن کے ساتھ ورچوئل مشینوں کو کاٹ دیا، ان پر Win10 پر آفس سافٹ ویئر انسٹال کیا اور جانچ شروع کی۔
ہم چلتے ہیں!
نظام
دو HPE SimpliVity 380 Gen10 نوڈس (سرور)۔ سب پر:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz۔
- RAM: 768GB، 12 x 64GB LRDIMMs DDR4 2666MHz۔
- پرائمری ڈسک کنٹرولر: HPE Smart Array P816i-a SR Gen10۔
- ہارڈ ڈرائیوز: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 کنفیگریشن میں، یعنی یہ HPE SimpliVity کی شرائط میں میڈیم ماڈل ہے)۔
- نیٹ ورک کارڈز: 4 x 1 جی بی ایتھ (صارف کا ڈیٹا)، 2 x 10 جی بی ایتھ (سادگی اور وی موشن بیک اینڈ)۔
- ڈپلیکیشن/کمپریشن کے لیے ہر نوڈ میں خصوصی بلٹ ان FPGA کارڈ۔
نوڈس ایک دوسرے سے 10Gb ایتھرنیٹ انٹرکنیکٹ کے ذریعے بغیر کسی بیرونی سوئچ کے براہ راست جڑے ہوتے ہیں، جو SimpliVity بیک اینڈ کے طور پر اور NFS کے ذریعے ورچوئل مشین ڈیٹا کی منتقلی کے لیے استعمال ہوتا ہے۔ کلسٹر میں ورچوئل مشین کا ڈیٹا ہمیشہ دو نوڈس کے درمیان عکس بند ہوتا ہے۔
نوڈس کو وی سینٹر کے زیر انتظام Vmware vSphere کلسٹر میں جوڑا جاتا ہے۔
جانچ کے لیے، ایک ڈومین کنٹرولر اور ایک Citrix کنکشن بروکر کو تعینات کیا گیا تھا۔ ڈومین کنٹرولر، بروکر اور vCenter ایک الگ کلسٹر پر رکھے گئے ہیں۔
ٹیسٹ انفراسٹرکچر کے طور پر، 300 ورچوئل ڈیسک ٹاپ ڈیڈیکیٹڈ - فل کاپی کنفیگریشن میں تعینات کیے گئے تھے، یعنی ہر ڈیسک ٹاپ ورچوئل مشین کی اصل تصویر کی مکمل کاپی ہے اور صارفین کی طرف سے کی گئی تمام تبدیلیوں کو محفوظ کرتا ہے۔
ہر ورچوئل مشین میں 2vCPU اور 4GB RAM ہوتی ہے:
جانچ کے لیے درکار درج ذیل سافٹ ویئر ورچوئل مشینوں پر انسٹال کیے گئے تھے۔
- ونڈوز 10 (64 بٹ)، ورژن 1809۔
- ایڈوب ریڈر XI۔
- Citrix ورچوئل ڈیلیوری ایجنٹ 1811.1.
- ڈورو پی ڈی ایف 1.82۔
- جاوا 7 اپ ڈیٹ 13۔
- مائیکروسافٹ آفس پروفیشنل پلس 2016۔
نوڈس کے درمیان - ہم وقت ساز نقل۔ کلسٹر میں ہر ڈیٹا بلاک کی دو کاپیاں ہوتی ہیں۔ یعنی اب ہر نوڈس پر ڈیٹا کا مکمل سیٹ موجود ہے۔ تین یا زیادہ نوڈس کے کلسٹر کے ساتھ، بلاکس کی کاپیاں دو مختلف جگہوں پر ہوتی ہیں۔ نیا VM بناتے وقت، کلسٹر نوڈس میں سے ایک پر ایک اضافی کاپی بنائی جاتی ہے۔ جب ایک نوڈ ناکام ہوجاتا ہے، تو اس پر پہلے چلنے والے تمام VM خود بخود دوسرے نوڈس پر دوبارہ شروع ہوجاتے ہیں جہاں ان کی نقلیں ہوتی ہیں۔ اگر کوئی نوڈ طویل عرصے تک ناکام ہو جاتا ہے، تو بتدریج فالتو پن کی بحالی شروع ہو جاتی ہے، اور کلسٹر N+1 فالتو پن پر واپس آ جاتا ہے۔
ڈیٹا بیلنسنگ اور اسٹوریج خود SimpliVity کے سافٹ ویئر اسٹوریج لیول پر ہوتا ہے۔
ورچوئل مشینیں ایک ورچوئلائزیشن کلسٹر چلاتی ہیں، جو انہیں سافٹ ویئر اسٹوریج پر بھی رکھتی ہے۔ ڈیسک خود ایک معیاری ٹیمپلیٹ کے مطابق لیے گئے تھے: فنانسرز اور آپریشنز آفیسرز کے ڈیسک ٹیسٹ کے لیے آئے تھے (یہ دو مختلف ٹیمپلیٹس ہیں)۔
ٹیسٹنگ
جانچ کے لیے، LoginVSI 4.1 سافٹ ویئر ٹیسٹ سوٹ استعمال کیا گیا تھا۔ لاگ ان وی ایس آئی کمپلیکس، جس میں ایک کنٹرول سرور اور ٹیسٹ کنکشن کے لیے 12 مشینیں شامل ہیں، کو ایک الگ فزیکل ہوسٹ پر تعینات کیا گیا تھا۔
جانچ تین طریقوں میں کی گئی تھی:
بینچ مارک موڈ - لوڈ کیسز 300 نالج ورکرز اور 300 اسٹوریج ورکرز۔
معیاری موڈ - لوڈ کیس 300 پاور ورکرز۔
پاور ورکرز کو کام کرنے اور بوجھ کے تنوع کو بڑھانے کے لیے، LoginVSI کمپلیکس میں اضافی پاور لائبریری فائلوں کی ایک لائبریری شامل کی گئی۔ نتائج کی تکرار کو یقینی بنانے کے لیے، تمام ٹیسٹ بینچ سیٹنگز کو بطور ڈیفالٹ چھوڑ دیا گیا تھا۔
نالج اینڈ پاور ورکرز ٹیسٹ ورچوئل ورک سٹیشنز پر کام کرنے والے صارفین کے حقیقی کام کے بوجھ کی نقل کرتے ہیں۔
سٹوریج ورکرز ٹیسٹ خاص طور پر ڈیٹا سٹوریج سسٹم کی جانچ کے لیے بنایا گیا تھا؛ یہ حقیقی کام کے بوجھ سے بہت دور ہے اور اس میں زیادہ تر مختلف سائز کی فائلوں کی ایک بڑی تعداد کے ساتھ کام کرنے والا صارف شامل ہوتا ہے۔
جانچ کے دوران، صارفین ہر 48 سیکنڈ میں تقریباً ایک صارف کی شرح سے 10 منٹ کے لیے ورک سٹیشن میں لاگ ان ہوتے ہیں۔
نتائج
LoginVSI ٹیسٹنگ کا بنیادی نتیجہ VSImax میٹرک ہے، جو صارف کی طرف سے شروع کیے گئے مختلف کاموں کی تکمیل کے وقت سے مرتب کیا جاتا ہے۔ مثال کے طور پر: نوٹ پیڈ میں فائل کھولنے کا وقت، 7-زپ میں فائل کو کمپریس کرنے کا وقت، وغیرہ۔
میٹرکس کے حساب کتاب کی تفصیلی وضاحت کے لیے سرکاری دستاویزات میں دستیاب ہے۔ .
دوسرے لفظوں میں، LoginVSI ایک عام لوڈ پیٹرن کو دہراتا ہے، آفس سوٹ میں صارف کے اعمال کی نقل کرتا ہے، پی ڈی ایف پڑھتا ہے، وغیرہ، اور مختلف تاخیر کی پیمائش کرتا ہے۔ تاخیر کی ایک اہم سطح ہے "سب کچھ سست ہوجاتا ہے، کام کرنا ناممکن ہے")، جس سے پہلے یہ سمجھا جاتا ہے کہ صارفین کی زیادہ سے زیادہ تعداد تک نہیں پہنچی ہے۔ اگر رسپانس ٹائم اس "سب کچھ سست ہے" حالت سے 1 ms تیز ہے، تو سمجھا جاتا ہے کہ سسٹم عام طور پر کام کر رہا ہے، اور مزید صارفین کو شامل کیا جا سکتا ہے۔
یہاں اہم میٹرکس ہیں:
میٹرکس
اٹھائے گئے اقدامات
تفصیلی تفصیل
بھری ہوئی اجزاء
N.S.L.D.
متن کھولنے کا وقت
فائل کا وزن 1 KB ہے۔
نوٹ پیڈ کھلتا ہے اور
ایک بے ترتیب 1 KB دستاویز کھولتا ہے جو پول سے کاپی کیا گیا ہے۔
وسائل
CPU اور I/O
این ایف او
مکالمے کے آغاز کا وقت
نوٹ پیڈ میں ونڈوز
VSI-Notepad فائل کھولنا [Ctrl+O]
CPU، RAM اور I/O
ZHC*
ایک انتہائی کمپریسڈ زپ فائل بنانے کا وقت
مقامی کمپریشن
بے ترتیب 5MB .pst فائل سے کاپی کی گئی۔
وسائل پول
CPU اور I/O
ZLC*
کمزور کمپریسڈ زپ فائل بنانے کا وقت
مقامی کمپریشن
بے ترتیب 5MB .pst فائل سے کاپی کی گئی۔
وسائل پول
I / O
CPU
بڑا حساب لگانا
بے ترتیب ڈیٹا سرنی
ایک بڑی صف بنانا
بے ترتیب ڈیٹا جو ان پٹ/آؤٹ پٹ ٹائمر میں استعمال کیا جائے گا (I/O ٹائمر)
CPU
جب ٹیسٹنگ کی جاتی ہے، ابتدائی طور پر بنیادی VSIbase میٹرک کا حساب لگایا جاتا ہے، جو اس رفتار کو ظاہر کرتا ہے جس پر سسٹم پر بوجھ کے بغیر ملازمتوں کو انجام دیا جاتا ہے۔ اس کی بنیاد پر، VSImax تھریشولڈ کا تعین کیا جاتا ہے، جو VSIbase + 1ms کے برابر ہے۔
سسٹم کی کارکردگی کے بارے میں نتیجہ دو میٹرکس کی بنیاد پر نکالا جاتا ہے: VSIbase، جو سسٹم کی رفتار کا تعین کرتا ہے، اور VSImax تھریشولڈ، جو کہ صارفین کی زیادہ سے زیادہ تعداد کا تعین کرتا ہے جسے سسٹم نمایاں انحطاط کے بغیر سنبھال سکتا ہے۔
300 نالج ورکرز بینچ مارک
نالج ورکرز وہ صارف ہیں جو مختلف چھوٹی چوٹیوں کے ساتھ میموری، پروسیسر اور IO کو باقاعدگی سے لوڈ کرتے ہیں۔ سافٹ ویئر مطالبہ کرنے والے دفتری صارفین کے کام کے بوجھ کی تقلید کرتا ہے، جیسے کہ وہ مسلسل کسی چیز (پی ڈی ایف، جاوا، آفس سویٹ، فوٹو ویونگ، 7-زپ) پر زور دے رہے ہوں۔ جیسے جیسے آپ صفر سے 300 تک صارفین کو شامل کرتے ہیں، ہر ایک کے لیے تاخیر آہستہ آہستہ بڑھتی جاتی ہے۔
VSImax شماریات کا ڈیٹا:
VSIbase = 986ms، VSI تھریشولڈ تک نہیں پہنچا تھا۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
اس قسم کے بوجھ کے ساتھ، نظام کارکردگی میں عملی طور پر کسی کمی کے بغیر بڑھے ہوئے بوجھ کو برداشت کر سکتا ہے۔ صارف کے کاموں کو مکمل کرنے میں جو وقت لگتا ہے وہ آسانی سے بڑھتا ہے، ٹیسٹنگ کے دوران سسٹم کے ردعمل کا وقت تبدیل نہیں ہوتا ہے اور لکھنے کے لیے 3 ms اور پڑھنے کے لیے 1 ms تک ہوتا ہے۔
: اختتام 300 علم والے صارفین موجودہ کلسٹر پر بغیر کسی دشواری کے کام کرتے ہیں اور ایک دوسرے کے ساتھ مداخلت نہیں کرتے، 1 سے 6 تک pCPU/vCPU اوور سبسکرپشن تک پہنچ جاتے ہیں۔ بوجھ بڑھنے کے ساتھ ہی مجموعی تاخیر یکساں طور پر بڑھتی ہے، لیکن مقررہ حد تک نہیں پہنچی ہے۔
300 اسٹوریج ورکرز بینچ مارک
یہ وہ صارفین ہیں جو بالترتیب 30 سے 70 کے تناسب میں مسلسل لکھتے اور پڑھتے ہیں۔ یہ ٹیسٹ مزید تجربات کی خاطر کیا گیا۔ VSImax شماریات کا ڈیٹا:
VSIbase = 1673، VSI حد 240 صارفین تک پہنچ گئی۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
اس قسم کا بوجھ بنیادی طور پر اسٹوریج سسٹم کا تناؤ کا امتحان ہے۔ جب اس پر عمل درآمد ہوتا ہے، تو ہر صارف مختلف سائز کی بہت سی بے ترتیب فائلیں ڈسک پر لکھتا ہے۔ اس صورت میں، یہ دیکھا جا سکتا ہے کہ جب کچھ صارفین کے لیے بوجھ کی ایک مخصوص حد سے تجاوز کر جاتا ہے، تو فائلوں کو لکھنے کے کاموں کو مکمل کرنے میں لگنے والا وقت بڑھ جاتا ہے۔ ایک ہی وقت میں، میزبانوں کے سٹوریج سسٹم، پروسیسر اور میموری پر بوجھ نمایاں طور پر تبدیل نہیں ہوتا، اس لیے فی الحال اس بات کا تعین کرنا ناممکن ہے کہ تاخیر کی وجہ کیا ہے۔
اس ٹیسٹ کا استعمال کرتے ہوئے سسٹم کی کارکردگی کے بارے میں نتیجہ صرف دوسرے سسٹمز پر ٹیسٹ کے نتائج کے مقابلے میں نکالا جا سکتا ہے، کیونکہ اس طرح کے بوجھ مصنوعی اور غیر حقیقی ہوتے ہیں۔ تاہم، مجموعی طور پر ٹیسٹ اچھا چلا گیا. 210 سیشنز تک سب کچھ ٹھیک رہا، اور پھر عجیب و غریب جوابات آنے لگے، جو لاگ ان VSI کے علاوہ کہیں نہیں دیکھے گئے۔
300 پاور ورکرز
یہ وہ صارفین ہیں جو سی پی یو، میموری اور ہائی آئی او کو پسند کرتے ہیں۔ یہ "طاقت استعمال کرنے والے" باقاعدگی سے پیچیدہ کاموں کو لمبے برسٹ کے ساتھ چلاتے ہیں، جیسے کہ نیا سافٹ ویئر انسٹال کرنا اور بڑے آرکائیوز کو کھولنا۔ VSImax شماریات کا ڈیٹا:
VSIbase = 970، VSI تھریشولڈ تک نہیں پہنچا تھا۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
جانچ کے دوران، سسٹم نوڈس میں سے ایک پر پروسیسر لوڈ کی حد تک پہنچ گئی تھی، لیکن اس کا اس کے آپریشن پر کوئی خاص اثر نہیں پڑا:
اس صورت میں، نظام کارکردگی میں نمایاں کمی کے بغیر بڑھے ہوئے بوجھ کو برداشت کر سکتا ہے۔ صارف کے کاموں کو مکمل کرنے میں جو وقت لگتا ہے وہ آسانی سے بڑھتا ہے، ٹیسٹنگ کے دوران سسٹم کے ردعمل کا وقت تبدیل نہیں ہوتا ہے اور لکھنے کے لیے 3 ms اور پڑھنے کے لیے 1 ms تک ہوتا ہے۔
گاہک کے لیے باقاعدہ ٹیسٹ کافی نہیں تھے، اور ہم مزید آگے بڑھے: ہم نے VM خصوصیات میں اضافہ کیا (اوور سبسکرپشن اور ڈسک کے سائز میں اضافے کا اندازہ کرنے کے لیے vCPUs کی تعداد) اور اضافی بوجھ شامل کیا۔
اضافی ٹیسٹ کرتے وقت، درج ذیل اسٹینڈ کنفیگریشن کا استعمال کیا گیا:
300vCPU، 4GB RAM، 4GB HDD کنفیگریشن میں 80 ورچوئل ڈیسک ٹاپس تعینات کیے گئے تھے۔
ٹیسٹ مشینوں میں سے ایک کی ترتیب:
مشینیں ڈیڈیکیٹڈ - فل کاپی آپشن میں تعینات ہیں:
اوور سبسکرپشن کے ساتھ 300 نالج ورکرز کا بینچ مارک 12
VSImax شماریات کا ڈیٹا:
VSIbase = 921 ms، VSI تھریشولڈ تک نہیں پہنچا تھا۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
حاصل کردہ نتائج پچھلے VM کنفیگریشن کی جانچ کرنے کے مترادف ہیں۔
300 پاور ورکرز 12 اوور سبسکرپشنز کے ساتھ
VSImax شماریات کا ڈیٹا:
VSIbase = 933، VSI تھریشولڈ تک نہیں پہنچا تھا۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
اس جانچ کے دوران، پروسیسر لوڈ کی حد تک بھی پہنچ گئی تھی، لیکن اس کا کارکردگی پر کوئی خاص اثر نہیں پڑا:
حاصل کردہ نتائج پچھلی ترتیب کی جانچ کی طرح ہیں۔
اگر آپ 10 گھنٹے لوڈ چلاتے ہیں تو کیا ہوتا ہے؟
اب دیکھتے ہیں کہ کیا کوئی "جمع اثر" ہوگا اور لگاتار 10 گھنٹے تک ٹیسٹ چلائیں گے۔
طویل مدتی ٹیسٹ اور سیکشن کی وضاحت کا مقصد اس حقیقت پر ہونا چاہئے کہ ہم یہ دیکھنا چاہتے ہیں کہ آیا اس پر طویل بوجھ کے تحت ٹراس کے ساتھ کوئی مسئلہ پیدا ہوگا۔
300 نالج ورکرز بینچ مارک + 10 گھنٹے
مزید برآں، 300 نالج ورکرز کے لوڈ کیس کا تجربہ کیا گیا، جس کے بعد صارف نے 10 گھنٹے کام کیا۔
VSImax شماریات کا ڈیٹا:
VSIbase = 919 ms، VSI تھریشولڈ تک نہیں پہنچا تھا۔
VSImax تفصیلی اعداد و شمار کا ڈیٹا:
گراف دکھاتا ہے کہ پورے ٹیسٹ میں کارکردگی میں کوئی کمی نہیں دیکھی گئی۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
سٹوریج سسٹم کی کارکردگی پورے ٹیسٹ میں یکساں رہتی ہے۔
مصنوعی بوجھ کے اضافے کے ساتھ اضافی جانچ
گاہک نے ڈسک میں جنگلی بوجھ ڈالنے کو کہا۔ ایسا کرنے کے لیے، صارف کے سسٹم میں لاگ ان ہونے پر ڈسک پر مصنوعی بوجھ چلانے کے لیے صارف کی ورچوئل مشینوں میں سے ہر ایک میں اسٹوریج سسٹم میں ایک ٹاسک شامل کیا گیا تھا۔ لوڈ fio یوٹیلیٹی کے ذریعہ فراہم کیا گیا تھا، جو آپ کو IOPS کی تعداد کے حساب سے ڈسک پر بوجھ کو محدود کرنے کی اجازت دیتا ہے۔ ہر مشین میں، 22 IOPS 70%/30% رینڈم ریڈ/رائٹ کی مقدار میں اضافی بوجھ شروع کرنے کے لیے ایک کام شروع کیا گیا تھا۔
300 نالج ورکرز بینچ مارک + 22 IOPS فی صارف
ابتدائی جانچ میں، fio کو ورچوئل مشینوں پر اہم CPU اوور ہیڈ لگاتے ہوئے پایا گیا۔ اس کی وجہ سے میزبانوں پر تیزی سے CPU اوورلوڈ ہوا اور مجموعی طور پر سسٹم کے آپریشن کو بہت متاثر کیا۔
میزبان CPU لوڈ:
ایک ہی وقت میں، اسٹوریج سسٹم میں تاخیر بھی قدرتی طور پر بڑھ گئی:
کمپیوٹنگ پاور کی کمی تقریباً 240 صارفین کے لیے اہم بن گئی:
حاصل کردہ نتائج کی وجہ سے، یہ فیصلہ کیا گیا کہ ٹیسٹنگ کا انعقاد کیا جائے جو کم سی پی یو انٹینسیو تھا۔
230 آفس ورکرز بینچ مارک + 22 IOPS فی صارف
CPU پر بوجھ کو کم کرنے کے لیے، آفس ورکرز کی لوڈ کی قسم کا انتخاب کیا گیا، اور ہر سیشن میں مصنوعی بوجھ کے 22 IOPS بھی شامل کیے گئے۔
ٹیسٹ 230 سیشنز تک محدود تھا تاکہ زیادہ سے زیادہ CPU بوجھ سے زیادہ نہ ہو۔
زیادہ سے زیادہ بوجھ کے قریب طویل مدتی آپریشن کے دوران سسٹم کے استحکام کو جانچنے کے لیے یہ ٹیسٹ 10 گھنٹے تک چلانے والے صارفین کے ساتھ چلایا گیا۔
VSImax شماریات کا ڈیٹا:
VSIbase = 918 ms، VSI تھریشولڈ تک نہیں پہنچا تھا۔
VSImax تفصیلی اعداد و شمار کا ڈیٹا:
گراف دکھاتا ہے کہ پورے ٹیسٹ میں کارکردگی میں کوئی کمی نہیں دیکھی گئی۔
CPU لوڈ کے اعداد و شمار:
اس ٹیسٹ کو انجام دیتے وقت، میزبانوں کے CPU پر بوجھ تقریباً زیادہ سے زیادہ تھا۔
SimpliVity مانیٹرنگ سے سٹوریج سسٹم لوڈ کے اعدادوشمار:
سٹوریج سسٹم کی کارکردگی پورے ٹیسٹ میں یکساں رہتی ہے۔
ٹیسٹ کے دوران اسٹوریج سسٹم پر بوجھ 6/500 کے تناسب میں تقریباً 60 IOPS تھا (40 IOPS پڑھا جاتا ہے، 3 IOPS لکھا جاتا ہے)، جو تقریباً 900 IOPS فی ورک سٹیشن ہے۔
جوابی وقت لکھنے کے لیے اوسطاً 3 ms اور پڑھنے کے لیے 1 ms تک۔
کل
HPE SimpliVity کے بنیادی ڈھانچے پر حقیقی بوجھ کی نقالی کرتے وقت، SimpliVity نوڈس کے جوڑے پر کم از کم 300 مکمل کلون مشینوں کے ورچوئل ڈیسک ٹاپس کو سپورٹ کرنے کے سسٹم کی صلاحیت کی تصدیق کرنے والے نتائج حاصل کیے گئے۔ ایک ہی وقت میں، سٹوریج سسٹم کا رسپانس ٹائم پوری جانچ کے دوران ایک بہترین سطح پر برقرار رکھا گیا۔
ہم طویل جانچ کے نقطہ نظر اور نفاذ سے پہلے حل کے موازنہ سے بہت متاثر ہوئے ہیں۔ اگر آپ چاہیں تو ہم آپ کے کام کے بوجھ کے لیے بھی کارکردگی جانچ سکتے ہیں۔ دیگر ہائپر کنورجڈ حل سمیت۔ متذکرہ صارف اب متوازی طور پر ایک اور حل پر ٹیسٹ مکمل کر رہا ہے۔ اس کا موجودہ انفراسٹرکچر ہر کام کی جگہ پر صرف پی سی، ایک ڈومین اور سافٹ ویئر کا ایک بیڑا ہے۔ بغیر ٹیسٹ کے VDI میں منتقل ہونا، یقیناً کافی مشکل ہے۔ خاص طور پر، حقیقی صارفین کو منتقل کیے بغیر VDI فارم کی حقیقی صلاحیتوں کو سمجھنا مشکل ہے۔ اور یہ ٹیسٹ آپ کو عام صارفین کو شامل کیے بغیر کسی خاص نظام کی حقیقی صلاحیتوں کا فوری جائزہ لینے کی اجازت دیتے ہیں۔ یہ وہ جگہ ہے جہاں سے یہ مطالعہ آیا ہے۔
دوسرا اہم نقطہ نظر یہ ہے کہ گاہک نے فوری طور پر مناسب پیمانہ کاری کا عہد کیا ہے۔ یہاں آپ ایک اضافی سرور خرید سکتے ہیں اور ایک فارم شامل کر سکتے ہیں، مثال کے طور پر، 100 صارفین کے لیے، صارف کی قیمت پر سب کچھ متوقع ہے۔ مثال کے طور پر، جب انہیں مزید 300 صارفین کو شامل کرنے کی ضرورت ہوتی ہے، تو وہ جان لیں گے کہ انہیں پہلے سے طے شدہ ترتیب میں دو سرورز کی ضرورت ہے، بجائے اس کے کہ وہ اپنے پورے انفراسٹرکچر کو اپ گریڈ کرنے پر دوبارہ غور کریں۔
HPE SimpliVity فیڈریشن کے امکانات دلچسپ ہیں۔ کاروبار جغرافیائی طور پر الگ ہے، اس لیے دور دراز کے دفتر میں اپنا الگ VDI ہارڈویئر انسٹال کرنا سمجھ میں آتا ہے۔ SimpliVity فیڈریشن میں، ہر ایک ورچوئل مشین کو ایک شیڈول کے مطابق نقل کیا جاتا ہے جس میں جغرافیائی طور پر دور دراز کے کلسٹرز کے درمیان بہت تیزی سے اور چینل پر بوجھ کے بغیر نقل تیار کرنے کی صلاحیت ہوتی ہے - یہ بہت اچھی سطح کا بلٹ ان بیک اپ ہے۔ سائٹس کے درمیان VMs کو نقل کرتے وقت، چینل کو کم سے کم استعمال کیا جاتا ہے، اور یہ ایک واحد کنٹرول سینٹر اور وکندریقرت اسٹوریج سائٹس کے ایک گروپ کی موجودگی میں بہت ہی دلچسپ DR فن تعمیر کو ممکن بناتا ہے۔
یہ سب مل کر مالیاتی پہلو کا بڑی تفصیل سے جائزہ لینا، اور کمپنی کے نمو کے منصوبوں پر VDI کی لاگت کو سپرپوز کرنا، اور یہ سمجھنا ممکن بناتا ہے کہ حل کتنی جلدی ادا کرے گا اور یہ کیسے کام کرے گا۔ کیونکہ کوئی بھی VDI ایک ایسا حل ہے جو بالآخر بہت سارے وسائل کو بچاتا ہے، لیکن ایک ہی وقت میں، زیادہ تر ممکنہ طور پر، استعمال کے 5-7 سال کے اندر اسے تبدیل کرنے کے قابل لاگت موقع کے بغیر۔
عام طور پر، اگر آپ کے کوئی سوالات ہیں جو تبصرہ کے لیے نہیں ہیں، تو مجھے ای میل کے ذریعے لکھیں۔ [ای میل محفوظ].
ماخذ: www.habr.com