10مورد از خطرناک‌ترین حملات سایبری در جهان- بخش دوم

Aurora (2010)

عصر حاضر سلاح های سایبری از اینجا شروع شد. حداقل می توان، شروع ابراز نگرانی عمومی در مورد Aurora را از اینجا دانست.

 

Aurora یک واقعۀ بهت برانگیز بود: ظاهرا هکرهای چینی در حال حمله به تعداد زیادی سازمان آمریکایی از جمله گوگل بودند، که این مورد با ابزار نگرانی توسط گوگل در معرض عموم همراه شد. تا این زمان بدافزارها مساله ای تلقی می شدند که فقط به تعداد کمی از مردم حمله می کنند: Aurora اشتباه بودن این موضوع را ثابت کرد. Aurora نه یک حملۀ پیچیده، بلکه حمله ای بی شرمانه بود که وزیر امور خارجه آمریکا، هیلاری کلینتون به خاطر آن از چین در معرض عموم به شدت انتقاد کرد. این اولین باری بود که یک کشور به طور علنی کشور دیگر را به خاطر حمله ی سایبری مقصر می دانست. در نهایت کشور چین مقصر دانسته شد. 

Stuxnet (2010)

استاکس نت هنوز هم مشهورترین سلاح سایبری در طول تاریخ است. اولین موردی است که به طور کامل مستندسازی شده است. وقتی در سال 2010 استاکس نت کشف شد، صنعت امنیت را دچار شوک کرد. بلافاصله محققان درک کردند که این بدافزار با موارد قبلی کاملا فرق دارد. این بدافزار سیستم های SCADA صنعتی را مورد تهاجم قرار داده و از چهار شکاف امنیتی مختلفِ Zero Day استفاده می کرد و دارای قسمت های مختلفی شبیه کرم بود که این قابلیت را داشت که بر روی حافظه های USB انتشار یابد. همه مردم دیدند که بیشترین تاثیر مخرب این بدافزار در ایران اتفاق افتاد. ادامه ماجرا برای همگان آشکار است. هیچ کس فکرش را هم نمی کرد که ایالات متحده این کار را کرده است یا حداقل مقصر دانسته شده است. کشورهایی که مقصر دانسته شدند ایالات متحده و اسرائیل بودند.

Flame (2012)

بدافزار شعله (flame) که با نام Skywiper هم شناخته می شود توسط چند شرکت امنیتی معرفی شد و ثابت کرد که استاکس نت صرفا یک مورد استثنایی و تصادفی نبوده است. شعله باز هم ایران و کشورهای خاورمیانه را هدف گرفته بود و دارای چند ماژول بود که هرکدام کارکرد خاصی را بر عهده داشتند و مشخص بود که سازندۀ آن، منابع کافی در اختیار دارد. استانداردهای بدافزار به خوبی در شعله رعایت شده بود. ویژگی شعله فقط پیچیدگی نبود، بلکه از روش های کاملا مخفیانه ای استفاده می کرد. یعنی Certificateهای مایکروسافت (منظور از certificate در اینجا داده هایی هستند که برای Authorization به کار می روند) را داشت و در عین حال کارکردهای Rootkit را هم داشت. در نهایت ایالات متحده و اسرائیل مقصر دانسته شدند.

10 مورد از خطرناک‌ترین حملات سایبری در جهان- بخش اول

سلاح‌های سایبری، جاسوسی سایبری، نظارت سایبری، مسائلی هستند که مدتی پیش حتی کسی از وجود آنها اطلاعی در دست نداشت. این مسائل از اهمیت بالایی برخوردارند. 
[نوشته شده توسط John E Dunn در 13 مارس 2015]

واقعا سخت است که باور کنیم جنگ مجازی و سلاح‌های مجازی، صرفا یک مسالۀ تئوری برای متخصصان امنیت بوده است و افراد دیگر، کاری با آن نداشتند. تا سال 2009 این طور پنداشته می‌شد که افرادی که به منظور انجام کارهای مخرب برنامه‌نویسی می‌کنند فقط بزهکاران و افرادی هستند که می‌خواهند از این راه به منافع مالی دست یابند، نه این که بخواهند اسرار کشورهای دیگر را سرقت کنند. 
این فرض باعث شد که شرکت‌های امنیتی، تمرکز خود را بر تهدیدهای مرتبط با مشتری، تجارت‌های خرد و تا حدود کمتری بر روی شرکت‌های بزرگ معطوف کنند. یعنی فرض بر این بود که دولت‌ها خودشان از عهدۀ مراقبت از خود بر می‌آیند. سپس در سال‌های 2010 و 2011 اخبار وسیع مرتبط با هکرهای چینی توسط تعدادی از شرکت‌های امنیتی تازه کار آمریکایی که جویای نام بودند برملا شد و پرده از واقعیت آنچه که در حال اتفاق افتاد بود برای همگان برداشته شد.
تا این زمان از رؤسای جمهور آمریکا انتظار می‌رفت که در مورد بدافزارهای دولتی و ایالتی اعلام نظر کنند که این مساله در مورد سیستم‌هایی که اولین بار سال‌ها قبل ساخته شده بودند (سال 2001) اتفاق افتاد. 
امروزه درک عمومی نسبت به این ابزارهای سایبر بسیار گسترش یافته است و این در حالی است که استفاده‌های بدخواهانه که بیشتر جنبۀ مخرب دارند تا پایش، چهرۀ واقعی خود را نشان داده اند. معمولا این مساله که بیشتر کشورها چنین نرم افزارهایی دارند دست‌کم گرفته می‌شود. شرکت‌های امنیتی بزرگ‌تر مخصوصا Kaspersky و Symantec سرمایه‌گذاری‌های عظیمی بر روی ردیابی این نرم افزارها می‌کنند چون با این کار تخصص خود را در راستای یافتن این تهدیدها به کار می‌برند. 
آیا این جنگ اطلاعاتی و این حیله گری از این هم وخیم تر خواهد شد؟ شواهد نشان می‌دهد که با هر روشی که بخواهیم با قدرت واقعی این نرم افزارها مقابله کنیم، احتمالا وضعیت از این هم وخیم تر خواهد شد. 
* تاریخ‌های ذکر شده، مربوط به کشف وقایع است، نه روی دادن آنها. 

حرکت دیتاسنترها به سمت "مبتنی بر نرم افزار" شدن

در طول 25 سال گذشته، فناوری هایی دیتاسنترها را تحت تاثیر قرار داده اند که صنعت IT را به طور کامل متحول کرده اند. از دورۀ دات کام تا عصر کلود و مجازی سازی تا تحول دیتاسنترهای مبتنی بر نرم افزار امروزی، دیتاسنترها به طور پیوسته در حال تکامل بوده اند.

در حرکت از معماری انحصاری با سیستم های اختصاصی به سمت مدل های مجازی‌سازی‌شده و مبتنی بر کلود که رایانش، شبکه و منابع ذخیره سازی را باهم یکپارچه می کند، دیتاسنترهای مبتنی بر نرم افزار قطعا چابکی تجارت را در آینده متحول خواهند کرد.

مفهوم NOC و عملکردها و مزایا و لزوم استفاده از این واحد از بخش فناوری اطلاعات در سازمان‌ها و شرکت‌ها

مراکز عملیات شبکه (NOCها) مراکزی هستند که در آنجا یک سازمانه شبکه کامپیوتری و زیرساخت‌های مخابراتی را مدیریت می‌کند، مشکلات موجود در زیرساخت IT را شناسایی و رفع می‌کند، و در نهایت از دسترسی  پذیری مرکز داده اطمینان حاصل می‌کند. گاهی اوقات این مراکز در داخل مرکز داده و گاهی خارج از آن واقع هستند. این مراکز معمولاً به خطوط اینترنت پرسرعت متصل هستند  یا مستقیماً به شبکه اصلی اینترنت متصل هستند تا بیشترین پهنای باند ممکن را در اختیار داشته باشند.

اما بدون در نظر گرفتن نوع چیدمان، هدف حفظ و نگهداری دسترس‌پذیری شبکه و دیتاسنتر به صورت پیوسته (24*7) می‌باشد. اگر مشکل مالی وجود نداشته باشد، این هدف همیشه قابل تحقق است. اما در جریان کاستن از هزینه های سازمانی و اقدامات مقرون به صرفه مشکلاتی می‌تواند رخ دهند. 

این مقاله کارکردهای NOC و همچنین روابط مختلف داخلی و بیرونی که می‌تواند بین مراکز داده و NOCها وجود داشته باشد را بررسی می‌کند. همچنین نکاتی به مدیران مراکز داده به منظور استفاده بهتر از منابع داخلی و بیرونی IT ارائه می‌دهد تا هزینه ها را کاهش دهند، بهره‌وری کارکنان را افزایش دهد، زمان حل مشکل را کاهش داده و تجربه کاربر نهایی را ارتقاء بخشد.

NOC در مقایسه با مرکز داده

اگر می‌خواهستید با Voltaire مکالمه داشته باشید، او خواستار تعریف شرایط شما می‌شد. بنابراین، ابتدا تعریفی روشن از یک NOC ارائه می‌دهیم، اینکه چگونه به مرکز داده متصل می‌شود و چه کارکردهای اصلی آن چیست. بخشی از چالش این است که سوال را از چه کسی می‌پرسید. 
آویشای شافیر (Avishai Shafir)، مدیر بازاریابی محصول در فراهم کننده سیاست امنیتی تنظیم تافین (Tufin)، می‌گوید مراکز داده با هدف میزبانی و مدیریت منابع محاسباتی سازمان مانند سرورها، ماشین‌های مجازی (VMها)، منابع ذخیره سازی و پایگاه های داده مورد استفاده قرار می‌گیرند. آنها بخشی از امور امنیت و کنترل شبکه را انجام می‌دهند. بعضی از این مراکز کوچک و بخشی از تاسیسات سازمان هستند در حالی که بعضی برای مدیریت دارایی هایی مانند سخت افزار، سیستم تهویه، برق، و امنیت فیزیکی بصورت مراکز مجزایی هستند.
بنابراین، تفاوت مرکز داده با NOC چیست؟ شافیر می‌گوید یک NOC بیشتر به بحث مرکز کنترل مدیریت ارتباط دارد. NOC زیرساخت و تغییرات پروسه‌ای، رخدادها، تماس‌های مشتریان، امنیت، کنترل کیفیت، ابزارهای نظارتی، سیستم‌های تیکتینگ، یکپارچه سازی با ابزارهای مشتری، گزارش دهی، ابزار کار با سیستم و غیره را مدیریت می‌کند. به همان اندازه که تکنولوژی مورد استفاده در NOC اهمیت دارد، عملیات آن و تیم پشتیبانی از آن نیز حائز اهمیت است. 
به نظر شافیر "بسیاری از مراکز داده اختصاصی دارای اتاق NOC داخلی برای مدیریت، نظارت، و حل مشکلات تجهیزات شبکه و IT هستند."
اندازه NOC (اتاق و تعداد مهندسان) معمولاً بستگی به اندازه مرکز داده و اهمیت تجاری آن دارد. تمامی مراکز داده دارای یک اتاق NOC و یک تیم دائمی نیستند. مراکز داده کوچکتر معمولاً از نرم افزارهای خودکار نظارت و حل مشکل به جای یک NOC استفاده می‌کنند تا امور را بدون دخالت انسان مدیریت کنند. 
مطابق با باور شافیر، تامین کنندگان خدمات مدیریت شده (MSPها( و شرکت‌های مخابراتی می بایست یک NOC در مرکز داده خود داشته باشند، زیرا شبکه، کارکرد و دسترسی به مرکز داده در این سازمان‌ها حائز اهمیت است. به همین ترتیب، شرکت‌های بزرگتر با تیم های IT بزرگ احتمالاً می‌توانند یک NOC مستقل ایجاد کنند و هزینه ها را پرداخت کنند. اما شرکت‌های دارای تیم IT کوچکتر احتمالاً از طریق برون سپاری NOC نتایج بهتری بدست خواهند آورد. 
تصمیم نهایی بایستی بر اساس اندازه تیم IT، سطح حساسیت کار شبکه، و میزان حساسیت داده ها یا شبکه ها باشد. به نظر شافیر "نکته مهم بعدی در این تصمیم گیری مقررات است (صنایعی مانند برق، آب و گاز بایستی دارای NOC داخلی باشند.)".
اچیسون فرازر (Atchison Frazer) که در زمان مصاحبه کارمند ارشد بازاریابی شرکت تحلیل و مدیریت داده ژانگاتی (Xangati) بود (وی در حال حاضر در شبکه‌های تالاری(Talari) مشغول به کار است)، برداشتی نسبتاً متفاوت دارد. به نظر او مراکز داده معمولاً درون شرکت قرار دارند، اگرچه امکان توزیع جغرافیایی آنها بر اساس تقاضای کاربر وجود دارد. NOCها اما معمولاً مجموعه 
ای از مراکز داده، چه فیزیکی و چه مجازی، هستند که می‌توان آنها را تحت نظارت داشت و در بعضی موارد از راه دور آنها را مدیریت کرد. 
فرازر می‌گوید " NOCها به شکلی گسترده در امنیت شبکه، سیستم های دفاعی/ جاسوسی/ نهادهای امنیت ملی، ارتباطات متمرکز/ و ارائه دهندگان خدمات تصاویر دیجیتال/ میزبانی/ سرویس‌ ابری مورد استفاده قرار می‌گیرند." 
INOC بعنوان شرکتی که یک NOC در اختیار دارد و خدمات نظارتی و مدیریت برای مراکز داده و تاسیسات محاسباتی ارائه می‌دهد، مراکز داده را بعنوان ساختمان‌هایی در نظر می‌گیرد که میزبان سرورها، تاسیسات ذخیره داده، شبکه و تجهیزات ارتباطی هستند؛ این مراکز معمولا نقاط ارتباط بین چندین شبکه حامل هستند. این تاسیسات دارای سیستم‌های تامین برق، تهویه، امنیت و شبکه مستحکمی هستند.
پیتر پروسن (Peter Prosen)، مدیر عملیات شبکه در INOC، تعریف متفاوتی از مرکز داده بعنوان مرکزی مجزا از NOC ارائه می‌دهد. به نظر این شرکت، NOCها مراکز کنترلی هستند که توسط تیم‌های دائمی مدیریت می‌شوند و پیوسته در زمینه های خدمات بهداشتی، و زیرساخت های مرتبط به مراکز داده، شرکت‌ها، ارائه دهندگان خدمات و سایر نهادها فعال هستند. 
به نظر پروسن، "یک مرکز داده همیشه دارای تیم پشتیبانی دائمی به انحاء مختلف است تا دسترسی فیزیکی دائمی برای کاربران فراهم باشد. همچنین خدمات پشتیبانی دائمی برای رفع مشکلات در تجهیزات و خطوط ارتباطی پیوسته وجود دارد." 
بنابراین مدیران مراکز داده می‌توانند یک NOC داخلی داشته باشند یا این خدمات را به یک تامین کننده NOC برون سپاری کنند. گزینه اول نیاز به توسعه کارکردهای داخلی و بیرونی تاسیسات موجود دارد تا بتوان تجهیزات نظارتی را در محل مستقر کرد. 
به نظر پروسن، یک مرکز داده در صورتی که از تکنولوژی ساده و تعداد محدودی تجهیزات استفاده کند و کارهای ضروری شامل کارهای ساده و تکراری باشد، می‌تواند بصورت داخلی مدیریت شود. علاوه بر این، اگر نیروی کار اضافی در سازمان وجود دارد، می‌توان از آنها در بخش مرکز داده بهره گرفت. با این حال وی هشدار می‌دهد که مدیران مراکز داده که دارای یک NOC 
داخلی هستند، تقریباً همیشه بایستی دو نفر نیروی کار آماده در خدمت داشته باشند. این مسئله البته از نظر نیروهای کار پر هزینه است، زیر بایستی شیفت‌هایی را به صورت دائمی ایجاد کرد.

مدیران مراکز داده بایستی در نظر داشته باشند که ممکن است راه اندازی یک NOC منطقی نباشد مگر این که کار کافی برای مشغول کردن نیروی کار وجود داشته باشد. اگر کار کافی وجود ندارد شاید برون سپاری NOC گزینه بهتری باشد. موانع دیگر برای ایجاد یک NOC داخلی می‌تواند قیمت‌های بالای ابزارهای مدیریت زیرساخت باشد. اگر مرکز داده، از قبل این زیرساخت‌ها را نداشته باشد، احتمالاً برون سپاری منطقی‌تر باشد. به همین صورت، نبود نیروی کار با استعداد می‌تواند باعث افزایش هزینه‌ها شود، زیرا بایستی نیرو کار مناسب به خدمت گرفته که هزینه بالایی به همراه دارد. 
به نظر پروسن، "برون سپاری NOC ضرورت تامین و نگهداری ابزارهای نرم افزاری، به خدمت گرفتن، آموزش، و مدیریت نیروی کار بیشتر را حذف می‌کند. اگر کار کافی برای کارکنان وجود ندارد، اگر تکنولوژی مورد نیاز پیچیده و گسترده است، اگر به خدمت گرفتن نیروی کار در فعالیت شما پرهزینه است، و مدیریت تجربه کافی در هدایت یک NOCندارد، برون سپاری گزینه بهتری است." 
روشن است، یک مدیر باهوش مرکز داده کل هزینه تملک (TCO) را در هر دو سناریو برون سپاری یا درونی سازی NOC قبل از تصمیم گیری نهایی در نظر میگیرد. نتایج در بسیاری مواقع جایی برای شک باقی نمیگذارند. برون سپاری NOC در صورتی که هزینه ایجاد و توسعه تاسیسات داخلی بیش از هزینه برون سپاری باشد، گزینه بهتری خواهد بود. به گفته پروسن، تامین کننده گان NOC معمولاً می‌توانند با استفاده تجهیزات و نیروی موجود برای ارائه خدمات به چند سازمان، از مزایای اقتصاد مقیاس بهره مند گردند. همچنین می‌توانند هزینه های مخابراتی خود را از طریق افزایش دسترسی و گزینه های ارتباطی موجود، کاهش دهند.

محدود کردن هزینه های NOC داخلی

اما تکلیف آنها که تصمیم می‌گیرند عملیات‌های NOC را به صورت داخلی نگهداری کنند چیست؟ پروسن می‌گوید یک راهکار مناسب برای مراکز داده به منظور کاهش هزینه هایNOC داخلی، کاهش تعداد هشدارها یا حوادثی است که در زیرساخت‌ها رخ 
می‌دهد. این به معنی داشتن یک زیرساخت با طراحی مناسب مستحکم و ظرفیت اضافی است. یک شاخص مهم در این زمینه مدیریت زیرساخت است.
به گفته پروسن "می‌توانید با استفاده از ابزارهای مناسب مدیریت زیرساخت که امکان هماهنگ سازی برنامه ها، خودکارسازی بعضی کارها و ارائه اطلاعات در مورد سلامت شبکه را دارند، هزینه ها را کاهش داد."
فرازر از شرک ژانگاتی پیشنهاد می‌کند از ابزارهای تحلیلی یکپارچه با کارآیی بالا در NOC داخلی مرکز داده استفاده شود، بطوری که اطمینان از در دسترس بودن خدمات قابل اندازه گیری باشد و کاهش در کیفیت یا گلوگاه ها را بتوان رفع کرد. با انجام صحیح این کار، می‌توان هزینه ها را کاهش داد. علاوه براین، این ابزارها دارای امکان استفاده از سنجه هایی را دارند که به مدیر مرکز داده کمک می‌کند میزان ظرفیت را در حد مناسبی حفظ کند و در عین حال برای آینده آماده باشد. این یک عنصر مهم در پیشگیری از خرید سخت افزار بیش از حد نیاز است. 
به نظر فرازر "تجربه کاربر نهایی مهمترین مسئله است، اما هر چه مرکز داده پیچیده تر باشد (برای مثال معماری ابر-ترکیبی)، امکان ارزیابی تجربه کاربر نهایی مشکل تر خواهد بود."
به منظور نظارت، ثبت، و تحلیل تمامی تعاملات بین برنامه های کاربردی، VMها و تمامی اجزای مجازی و فیزیکی مرکز داده، ژانگاتی از نظارت آنی در سیستم‌های کاربر نهایی استفاده می‌کند. بیش از 300 شرکت، سازمان دولتی، سازمان بهداشتی، سیستم های آموزشی و تامین کنندگان خدمات از ژانگاتی استفاده می‌کنند، از جمله Univita Health، Comcas،British Gas ، دانشگاه هاروارد و ارتش امریکا. 
شافیر و تافین نیز در مورد کاهش هزینه های NOC با استفاده از ابزارهای صحیح صحبت کرده اند. برای مثال ابزارهای نظارتی متعدد و همچنین نرم افزارهای رفع مشکل متعددی وجود دارند که می‌توان از آنها برای حصول اطمینان از عملکرد صحیح سیستم استفاده کرد. به این ترتیب می‌توان از هزینه ها کاست، زیرا نیروی کار کمتری مورد نیاز خواهد بود و زمان لازم برای یافتن مشکل و حل آن کاهش خواهد یافت. 
مورد نظارت و مدیریت بر کنترل‌های امنیتی مانند دیوارهای آتش را در نظر بگیرید. بعضی مراکز داده دارای صدها دیوار آتش هستند و هر یک بر اساس قواعد خاصی عمل می‌کنند و این دیوارها نیاز به بروزرسانی روزانه دارند. هر گونه تغییر در یکی از هزاران تنظیمات این دیوارهای آتش می‌تواند منجر به قطع ارتباط یا کاهش کارآیی شوند (که باعث افزایش هزینه های کلی خواهد شد).
به نظر شافیر "تیم NOC نیازمند مجموعه مناسبی از ابزارها جهت نظارت و حل مسائل دیوارهای آتش است، تا بتواند عامل اصلی مشکل احتمالی را به دلیل تغییر در پیکربندی سیستم امنیتی را شناسایی کند. علاوه بر این، تیم NOC بایستی اطمینان حاصل کنند که رفع مشکل پیکربندی دیوار آتش باعث ایجاد حفره امنیتی و ایجاد آسیب پذیری در شبکه شرکت نمی‌شود."

زمان لازم را صرف کنید

می‌توان مثال‌های کاملاً قانع کننده‌ای را در جهت برون سپاری NOC ارائه داد. همچنین می‌توان مثال‌هایی در جهت درونی سازی NOC ارائه داد. در نظر گرفتن تمامی مسائل پیش از اخذ تصمیم نهایی وظیفه مدیر مرکز داده است. 
مهمترین مسئله هزینه است. آیا در نهایت برون سپاری ارزانتر است؟ برای اینکه تمامی مسائل به درستی بررسی شوند، جزئیات معادله هزینه را به دقت بررسی کنید تا هزینه دقیق هر تصمیم را بدست بیاورید. 
با اینحال و صرفنظر از تصمیمی که گرفته می‌شود، داشتن یک NOC و ارائه خدمات با کیفیت هزینه بر است. بنابراین، در تصمیم گیری عجله نکنید. تمامی نتایج مالی در پی نبودن خدمات NOC را در نظر بگیرید. بدون وجود NOC رتبه بندی دسترسی به مرکز داده می‌تواند بشدت کاهش پیدا کند و منابع کارکنان مرکز داده می‌تواند صرف رفع مشکلاتی شود که امکان پیشگیری از آن وجود داشته. 
ژرژ شولز (Greg Schulz) تحلیل گیر گروه سرور و ذخیره سازی IO می‌گوید "فراتر از هزینه های جاری و احتمالی را ببینید و ارزشی را که از طریق هزینه صرف شده به دست میاید، در نظر بگیرید."
وی از مدیران مرکز داده می‌خواهد که از خود بپرسند آیا عملی که انجام می‌دهد جابجا کردن یا به تعویق انداختن هزینه هاست، مخفی کردن یا رفع یک مشکل است، یا اینکه امکان دسترسی به ارزش بیشتر و افزایش اطمینان به سیستم را فراهم می‌کنند. به جای اینکه مسئله را صرفاً هزینه در نظر بگیرید، بررسی کنید چگونه این تصمیم می‌تواند باعث تکمیل و تقویت خدمات شود. 
شولز می‌گوید " NOCها را از دیدگاه دارایی تجاری استراتژی در نظر بگیرد و نه صرفاً یک هزینه سربار."

محدودیت های vSphere 6.5_بخش هشتم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
در مطلب گذشته به شرح محدودیت های VMware vSphere Flash Read Cache و VMware Virtual SAN پرداختیم.در این قسمت Storage Policies ،Network I/O Control(NIOC) ،Virtual Volumes و Managed Virtual Disks توضیح داده می شوند.
8. Virtual Volumesاطمینان حاصل کنید که حجم Virtual Volumeها را با توجه به حداکثر محدودیت های تعریف شده تنظیم نمائید.
9. (Network I/O Control (NIOCاطمینان حاصل کنید که کنترل VMware vSphere Network I/O با توجه به حداکثر محدودیت های تعریف شده، تنظیم شده باشد.
10. Storage Policiesحداکثر ظرفیت Storage Policy نشان دهنده محدودیت های Storage Policy است.
11. Managed Virtual Disksشما باید Managed Virtual Diskها را با توجه به حداکثر محدودیت های تعریف شده، تنظیم کنید.

محدودیت های vSphere 6.5- بخش هفتم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
در مطلب گذشته به شرح محدودیت های vCenter Server Extensionها پرداختیم در این قسمت محدودیت های VMware vSphere Flash Read Cache و VMware Virtual SAN توضیح داده می شوند.
6. محدودیت های VMware vSphere Flash Read Cache
از پیکربندی vMware vSphere Flash Read Cache در محدودیتی که توسط Flash Read Cache مشخص شده است، اطمینان حاصل کنید.

7. محدودیت های VMware Virtual SAN
حداکثر ظرفیت VMware Virtual SAN محدودیت های قابل اجرا در:
Virtual SAN VM Storage Policy ،Virtual Machines ،Virtual SAN ،Virtual SAN Cluster ،Virtual SAN ESXi Host و Virtual Networking را نشان می دهند. 

محدودیت های vSphere 6.5- بخش ششم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
در مطلب گذشته به شرح محدودیت های Platform Services Controller پرداختیم در این قسمت محدودیت های vCenter Server Extensionها توضیح داده می شوند.
5. محدودیت های vCenter Server Extensionها
حداکثر ظرفیت vCenter Server Extensionها نشان دهنده ی محدودیت های VMware vCenter Update Manager ،VMware vCenter Orchestrator و Storage DRS می باشد.
5.1 محدودیت های VMware vCenter Update Manager
حداکثر ظرفیت VMware vCenter Update Manager نشان دهنده ی محدودیت های مربوط به عملیات های همزمان می باشد.

5.2 محدودیت های VMware vRealize Orchestrator
حداکثر ظرفیت VMware vRealize Orchestrator نشان دهنده ی محدودیت های سیستم های vCenter Server، موارد ESXi، ماشین های مجازی و Workflowهای پشتیبانی شده می باشد.

محدودیت های vSphere 6.5- بخش پنجم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

 

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
در مطلب گذشته به شرح محدودیت های vCenter Server پرداختیم در این قسمت محدودیت های Platform Services Controller توضیح داده می شوند.
4. محدودیت های Platform Services Controller
حداکثر ظرفیت Platform Services Controllerها نشان دهنده محدودیت های Enhanced Linked Mode ،Identity Source ،Replication ،Domain یا Lookup Service و VMware Certificate Authority (VMCA) می باشد.

محدودیت های vSphere 6.5- بخش چهارم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
در مطلب گذشته به شرح محدودیت های ESXi Host پرداختیم در این قسمت محدودیت های vCenter Server توضیح داده می شوند.
3. محدودیت های vCenter Server
حداکثر ظرفیت vCenter Server، محدودیت های مقیاس پذیریِ vCenter Server، رابط کاربری، پردازش همزمان و  vCenter Server Appliance را نشان می دهد. 

3.1. Storage DRSاز تنظیمات DRS مربوط به Storage خود اطمینان حاصل کنید تا با توجه به محدودیت های تعریف شده برای Storage DRS تنظیم شده باشند.

محدودیت های vSphere 6.5- بخش سوم

وقتی تجهیزات مجازی و فیزیکی خود را انتخاب و پیکربندی می کنید، باید به محدودیت های تعیین شده توسط VMware vSphere 6.5 نیز توجه کنید.

محدودیت هایی که در قسمت های زیر می آید محدودیت های تست شده و توصیه شده را بیان می کند و به طور کامل توسط VMware پشتیبانی می شود.
2. محدودیت های ESXi Host
محدودیت های ESXi host: محدودیت های پردازش، حافظه، ذخیره سازی، محدودیت های Networking، محدودیت های (حداکثر ظرفیت) کلاستر و Resource Pool و محدودیت گرافیک ESXi را نشان می دهد. 
در مطلب گذشته به شرح محدودیت های حافظه و ذخیره سازی پرداختیم در این قسمت محدودیت های Networking، محدودیت های (حداکثر ظرفیت) کلاستر و Resource Pool و محدودیت گرافیک ESXi توضیح داده می شوند.
2.4 محدودیت های Networking:
حداکثرتنظیمات قابل دسترسی در یک شبکه، نشان دهنده محدودیت های یک شبکه در جایی که هیچ محدودیت دیگری اعمال نشده است می باشد (برای نمونه به محدودیت های vCenter Server اشاره می کنیم؛ وقتی سیستمی بزرگ در حال پیاده سازی می باشد باید ویژگی هایی از قبیل HA ،DRS و دیگر تنظیماتی که ممکن است با محدودیت مواجه شوند را در نظر گرفت).

2.5 محدودیت های (حداکثر ظرفیت) کلاستر و Resource Pool:
حداکثر ظرفیت ESXi hostهای کلاستر و Resource Poolها نشان دهنده محدودیت های موجود در کلاستر و Resource Pool می باشند.

2.6 محدودیت گرافیک ESXi:
حداکثر گرافیک ESXi نشان دهنده ی محدودیت حافظه ی گرافیکی ESXi می باشد.