نحوه پیکربندی Pool در خانواده Dell Unity – آشنایی با Pool
Storage Pool در Dell Unity جایی است که ویژگی های ذخیره سازی از همان ابتدا شکل می گیرد؛ از نوع Drive و ظرفیت گرفته تا سیاست های RAID و نحوه کنارگذاشتن spare. اگر Pool درست انتخاب و درست طراحی شود، ساخت Storage Resource و توسعه ظرفیت در ادامه مسیر با دردسر کمتر و تصمیم های شفاف تر پیش می رود. این مقاله، چارچوب لازم را می دهد تا انتخاب و پیکربندی Pool با دید عملی و قابل اجرا انجام شود.
معرفی Pool در Dell Unity Storage
Pool مجموعه ای از Driveهاست که ویژگی های مشخص ذخیره سازی را برای Resourceهایی که از آن استفاده می کنند فراهم می کند. هنگام ایجاد یک Storage Resource جدید، Pool همان نقطه ای است که تعیین می شود ظرفیت و نوع ذخیره سازی از کجا تأمین شود. اگر سیستم چند نوع Drive داشته باشد، امکان تعریف Tierهای مختلف در Pool وجود دارد و هر Tier می تواند با تنظیمات مرتبط خودش مدیریت شود. این نگاه، پایه تصمیم های بعدی در طراحی و بهره برداری از Storage را محکم می کند.
اصول پایه طراحی Pool پیش از کانفیگ
قبل از هر اقدامی در ساخت Storage Resource، باید منطق Pool روشن باشد؛ چون تغییرات بعدی محدود و پرهزینه است. در طراحی اولیه Pool، چند قانون کلیدی وجود دارد که مسیر کانفیگ را قابل پیش بینی می کند.
این بخش روی قواعدی تمرکز دارد که معمولاً در پروژه های واقعی، جلوی دوباره کاری و توقف های ناگهانی را می گیرد.
الزام ایجاد Pool قبل از Storage Resource
قبل از ایجاد Storage Resourceها، باید حداقل یک Pool پیکربندی شده باشد. هنگام ساخت Storage Resource مشخص می شود از کدام Pool استفاده می شود و فضای مصرفی همان Resource از Pool انتخاب شده تأمین خواهد شد. این وابستگی باعث می شود تصمیم Pool، یک تصمیم «زیرساختی» باشد و بهتر است قبل از هر تخصیص، دقیق انجام شود.
محدودیت های تغییر Pool (عدم امکان shrink)
Pool قابلیت shrink شدن ندارد و تغییر ویژگی های ذخیره سازی آن بدون حذف Storage Resourceهای داخل Pool و خود Pool ممکن نیست. این محدودیت، طراحی اولیه را حساس می کند و معمولاً نیاز به پیش بینی رشد و سیاست های RAID را افزایش می دهد. در نتیجه، بهتر است Pool با نگاه به آینده انتخاب شود تا مجبور به حذف و بازسازی نشود.
امکان expand کردن Pool با اضافه کردن Drive
با وجود محدودیت در shrink، امکان expand کردن Pool با اضافه کردن Drive وجود دارد. این ویژگی کمک می کند ظرفیت با رشد نیازها افزایش پیدا کند، بدون آنکه الزاماً همه چیز از نو ساخته شود. با این حال، شیوه expand در Dynamic و Traditional یکسان نیست و باید مطابق قواعد همان نوع Pool انجام شود.
انواع Pool در Dell Unity
Unity بسته به Unity model و نسخه Unity OE از دو نوع Pool پشتیبانی می کند: Dynamic Pool و Traditional Pool. شناخت دقیق این دو، انتخاب صحیح را ساده تر می کند و از طراحی ناسازگار جلوگیری می شود.
در این بخش، نوع Poolها معرفی می شوند تا در مراحل بعدی، تصمیم گیری بر پایه مدل و نیاز عملی انجام شود.
Dynamic Pool
Dynamic Pool در Unity All-Flash modelهایی که OE نسخه 4.2.x یا بالاتر دارند به صورت گسترده استفاده می شود. در این معماری، RAID به شکل پیشرفته روی drive extentها توزیع می شود و spare space هم داخل خود Pool پخش خواهد شد. نتیجه این طراحی معمولاً انعطاف بیشتر در توسعه ظرفیت و رفتار متفاوت در سناریوهای خرابی Drive است.
مدل های پشتیبانی شده
در All-Flash modelهایی که Unity OE نسخه 4.2 و بالاتر را اجرا می کنند، هم Dynamic Pool و هم Traditional Pool پشتیبانی می شود. در این مدل ها، Poolهای جدیدی که در Unisphere GUI ساخته می شوند Dynamic هستند. Poolهایی که با Unisphere CLI یا REST API ساخته می شوند می توانند Dynamic (پیش فرض) یا Traditional باشند. ایجاد Traditional در GUI ممکن نیست، اما مدیریت Traditional موجود در GUI انجام می شود.
نحوه پیاده سازی RAID و spare space
در Dynamic Pool، یک RAID Group روی drive extentها و در چند Drive مختلف توزیع می شود. spare space موردنیاز هم به جای یک Drive ثابت، روی extentهای چند Drive داخل Pool پخش می شود. این طراحی باعث می شود ظرفیت بلااستفاده به شکل «fixed spare» وجود نداشته باشد و Driveهای بیشتری در ظرفیت عملی Pool نقش داشته باشند.
رفتار Pool هنگام Drive failure
وقتی یک Drive fail می شود، extentهای روی Drive معیوب روی spare space extentهای داخل Pool rebuild می شوند. چون spare capacity در چند Drive پخش است، Driveهای بیشتری در rebuilding مشارکت می کنند.
به همین دلیل، زمان های rebuild معمولاً سریع تر گزارش می شود و فشار بازسازی روی یک hot spare واحد متمرکز نیست.
Traditional Pool
Traditional Pool در UnityVSA modelها، Hybrid modelها و All-Flash modelهایی که OE نسخه 4.1.x یا پایین تر دارند نوع اصلی Pool است. این ساختار بر پایه RAID Groupها مدیریت می شود و توسعه ظرفیت هم تابع همین منطق است. در عین سادگی مفهومی، محدودیت های RAID Group و hot spare اختصاصی، رفتار خاصی در توسعه و بازسازی ایجاد می کند.
مدل های پشتیبانی شده
All-Flash modelهایی با Unity OE نسخه 4.1x و پایین تر، و همچنین همه Hybrid modelها و VSA modelها فقط Traditional Pool را پشتیبانی می کنند. در All-Flash با OE نسخه 4.2.x یا بالاتر هم امکان ساخت Traditional با CLI یا REST API وجود دارد.با Unisphere GUI امکان ایجاد Traditional Pool وجود ندارد، اما مدیریت Traditional Poolهای موجود از طریق GUI انجام می شود.
ساختار مبتنی بر RAID Group
در physical deployments، Storage در Traditional Poolها در قالب RAID Group مدیریت می شود. هر Drive توسط یک RAID Group واحد مصرف می شود و هر RAID Group حداکثر 16 Drive دارد. هر RAID Group از Driveهای یک type یکسان تشکیل می شود و هر Tier فقط از یک RAID type پشتیبانی می کند؛ همین موضوع، طراحی را دقیق تر و توسعه را مرحله ای می کند.
نحوه مدیریت Drive و spare
Traditional Poolها از dedicated hot spare برای جایگزینی Drive fail یا faulted استفاده می کنند. هر Drive استفاده نشده با فناوری و اندازه مناسب می تواند spare شود و اگر هم اندازه نباشد، Drive بزرگ تر با همان type قابل استفاده است. از آنجا که hot spare اختصاصی است، برای بهبود performance یا کاهش wear فلش استفاده نمی شود و rebuild هم به صورت کامل روی همان یک spare Drive انجام می شود.
معیارهای انتخاب Dynamic Pool یا Traditional Pool
انتخاب بین Dynamic Pool و Traditional Pool باید بر پایه مدل سیستم، نسخه OE و هدف های عملیاتی انجام شود. این انتخاب روی نحوه توسعه ظرفیت، رفتار در خرابی و حتی نحوه کنارگذاشتن spare اثر مستقیم دارد.
در این بخش، معیارها به شکلی چیده شده اند که تصمیم گیری سریع تر و قابل دفاع تر انجام شود.
Unity model و نسخه Unity OE
نوع Pool به Unity model و نسخه Unity OE وابسته است. در All-Flash با OE نسخه 4.2 و بالاتر، Dynamic و Traditional هر دو قابل استفاده اند، اما GUI به صورت پیش فرض Dynamic می سازد. در Hybrid و VSA و All-Flashهای قدیمی تر، Traditional انتخاب اصلی است و مسیر کانفیگ هم بر اساس RAID Group شکل می گیرد.
نیازهای performance و توسعه پذیری
Dynamic Pool معمولاً زمان rebuild سریع تری دارد چون spare capacity بین چند Drive پخش است و Driveهای بیشتری در rebuilding مشارکت می کنند. همچنین expand در Dynamic می تواند با افزودن تعداد کمتر Drive هم انجام شود و انعطاف بیشتری در provisioning ایجاد می کند.
در Traditional، توسعه ظرفیت معمولاً نیازمند اضافه کردن Driveها به شکل incrementهای RAID Group است و این موضوع می تواند حداقل ظرفیت قابل افزودن را بزرگ تر کند.
ملاحظات هزینه و آینده نگری
Dynamic Pool به دلیل نبود fixed spare و امکان اضافه کردن Driveهای بیشتر به یک Pool، می تواند از ظرفیت موجود بهتر استفاده کند و load را بین Driveهای بیشتری پخش کند. این موضوع روی عمر Driveهای Pool هم اثر مثبت دارد. در Traditional، dedicated hot spareها خارج از استفاده عملی Pool می مانند و با افزایش ظرفیت Drive، حداقل مقدار Storage قابل افزودن و هزینه آن می تواند بزرگ تر شود.
معماری RAID و مدیریت Driveها
RAID در Dell Unity فقط یک انتخاب عددی نیست؛ به شکل مستقیم روی نحوه توزیع داده، توسعه ظرفیت و رفتار خرابی اثر می گذارد. هر نوع Pool، منطق خاصی برای RAID، stripe width و مدیریت Drive دارد. در این بخش، ساختار RAID در Dynamic و Traditional به صورت قابل اجرا تفکیک می شود.
RAID در Dynamic Pool
Dynamic Pool از RAID پیشرفته ای استفاده می کند که روی drive extentها پخش می شود. به همین دلیل، رفتار بازسازی و حتی توسعه ظرفیت، معمولاً یکپارچه تر و توزیع شده تر دیده می شود. با این حال، برخی تنظیمات پس از ایجاد Pool ثابت می ماند و باید از ابتدا درست انتخاب شود.
stripe width و محدودیت تغییر
پس از ایجاد Dynamic Pool، RAID type یا stripe width قابل تغییر نیست. این محدودیت باعث می شود انتخاب اولیه stripe width برای هر ترکیب drive type/ظرفیت مهم شود. اگر Pool با یک drive type متفاوت expand شود، Driveهای اضافه شده می توانند stripe width متفاوتی داشته باشند، اما تنظیمات بخش های قبلی ثابت می ماند.
توزیع RAID روی drive extentها
در Dynamic Pool، RAID Group روی drive extentها در چند Drive مختلف توزیع می شود. spare space هم روی extentهای چند Drive پخش می شود و به یک hot spare Drive واحد وابسته نیست. وقتی خرابی رخ دهد، extentهای معیوب روی spare space داخل Pool بازسازی می شوند و فرآیند به مشارکت چند Drive تکیه دارد.
RAID در Traditional Pool
Traditional Pool در physical deployments با RAID Groupها مدیریت می شود. این ساختار باعث می شود هر تصمیم RAID، مستقیماً روی واحدهای توسعه ظرفیت و ترکیب Driveها اثر بگذارد. در عوض، کنترل طراحی در قالب گروه های مشخص، برای برخی سناریوها قابل پیش بینی و روشن است.
RAID Group و محدودیت تعداد Drive
هر RAID Group حداکثر 16 Drive دارد و هر Drive فقط توسط یک RAID Group مصرف می شود. این موضوع باعث می شود توسعه ظرفیت به شکل اضافه کردن گروه های جدید یا افزایش گروه های موجود انجام شود. برای مثال، اگر (RAID 5 (4+1انتخاب شود، برای افزودن ظرفیت باید حداقل 5 Drive به Pool اضافه شود.
وابستگی RAID به drive type
هر RAID Group از Driveهای یک type یکسان ساخته می شود و هر Tier فقط از یک RAID type پشتیبانی می کند. این وابستگی باعث می شود ترکیب drive typeها و ساخت Tierها در Traditional بسیار تعیین کننده باشد.
در زمان expand یا اضافه کردن Tier جدید، امکان انتخاب RAID type و stripe width متفاوت برای Driveهای تازه اضافه شده وجود دارد.
مدیریت Spare و سناریوهای Fail
Spare در Dell Unity فقط یک ظرفیت رزرو شده نیست؛ روی زمان بازگشت سرویس، فشار روی Driveها و حتی احتمال failureهای زنجیره ای اثر می گذارد. تفاوت Dynamic و Traditional در همین نقطه کاملاً دیده می شود. این بخش، سیاست spare و رفتار rebuild را طوری توضیح می دهد که موقع کانفیگ، تصمیم ها روشن باشد.
hot spare در Dynamic Pool
در Dynamic Pool، به جای رزرو کردن hot spare Drive خارج از Pool، از spare space داخل خود Pool استفاده می شود. به صورت پیش فرض، به ازای هر 32 Drive، ظرفیتی معادل یک Drive به عنوان spare space کنار گذاشته می شود. گزینه 2/32 هم وجود دارد که spare space را دو برابر می کند و پس از پیکربندی، برای طول عمر Pool ثابت و غیرقابل تغییر خواهد بود.
dedicated hot spare در Traditional Pool
Traditional Poolها از dedicated hot spare استفاده می کنند و هر Drive استفاده نشده با فناوری و اندازه مناسب می تواند spare باشد. سیستم معمولاً به ازای هر گروه 1 تا 31 Drive با type و ظرفیت و سرعت چرخش یکسان، یک spare Drive reserve می کند.
این spare Driveها برای بهبود performance یا کاهش Flash wear به کار گرفته نمی شوند و نقششان فقط جایگزینی در خرابی است.
فرآیند rebuild و اثر آن بر performance
در Dynamic Pool، چون spare capacity بین چند Drive توزیع است، Driveهای بیشتری در rebuilding مشارکت می کنند و زمان rebuild معمولاً سریع تر است. این رفتار کمک می کند فشار بازسازی پخش شود و روند بازگشت ظرفیت پایدارتر باشد. در Traditional، کل Drive باید روی یک spare Drive rebuild شود و زمان rebuild می تواند طولانی شود؛ چون به performance همان Drive محدود است و این موضوع می تواند روی performance اثر بگذارد و ریسک failureهای اضافی را بالا ببرد
Storage Tierها در Pool
Storage tierها لایه بندی Driveها را به شکل قابل مدیریت تبدیل می کنند و انتخاب درست Tier می تواند هم performance و هم هزینه را متعادل کند. در Unity، تعریف Tier برای physical و virtual deployment معنا دارد، اما روش ارتباط Tier متفاوت است.
Extreme Performance tier
این Tier از Driveهای Solid State با extreme performance تشکیل می شود: SAS Flash 2، SAS Flash 3 و SAS Flash 4. زمان های دسترسی بسیار سریع برای workload متغیر فراهم می کند و برای نمونه، databaseها می توانند با SAS Flash به performance بالایی برسند.در physical deployments، Default RAID configuration این Tier برابر(RAID 5 (8+1 ذکر شده است و محدودیت های FAST Cache و FAST VP هم وابسته به نوع SAS Flash است.
Performance tier
Performance tier با SAS (Rotating performance drive) تعریف می شود و performance همه جانبه با response timeهای پایدار و throughput بالا ارائه می دهد. این Tier برای Resourceهای database که به صورت متمرکز از طریق شبکه access می شوند مناسب است. Default RAID configuration در physical deployments برای این Tier برابر( RAID 5 (4+1 آمده است.
Capacity tier
Capacity tier با NL-SAS (Rotating capacity drive) بیشترین ظرفیت را با performance کلی پایین تر فراهم می کند. برای داده های عمدتاً static مثل فایل های ویدیویی، صوتی و تصویر مناسب است و برای workloadهایی که الزام سخت گیرانه performance ندارند انتخاب اقتصادی تری است.
برای داده ای که زیاد تغییر می کند یا زیاد access می شود، performance این Tier به مراتب پایین تر است و Default RAID configuration آن RAID 6 6+2 ذکر شده است.
تفاوت Tier در physical و virtual deployments
در physical deployments، Storage tier با physical drive type مرتبط است. در virtual deployments، Storage tier با ویژگی های زیرساختی virtual disk مرتبط است و باید به صورت دستی assigned شود.
اگر FAST VP نصب باشد، امکان ساخت tiered pool وجود دارد تا drive utilization بهینه شود و Pool از چند drive type تشکیل شود، مانند SAS Flash 2 و SAS.
طراحی Pool برای All-Flash و Hybrid
نوع Pool از نظر All-Flash یا Hybrid بودن، رفتار performance و برخی قابلیت ها را محدود یا تقویت می کند. در متن، تفاوت ها و توصیه ها به شکل مستقیم گفته شده و این بخش بر همان نکات تکیه دارد. هدف این قسمت، آماده کردن تصمیم های طراحی است تا کانفیگ بعدی روی پایه درست انجام شود.
All-Flash Pool
All-Flash Pool بالاترین سطح performance را در Unity ارائه می دهد و برای applicationهایی مناسب است که کمترین response time و بالاترین performance ذخیره سازی را می خواهند. Snapshotها و replication در All-Flash با بالاترین کارایی عمل می کنند. Compression فقط در All-Flash Poolها پشتیبانی می شود و FAST Cache و FAST VP برای All-Flash Poolها قابل اعمال نیست.
ویژگی ها و محدودیت ها
در All-Flash Pool، تمرکز روی حداکثر performance است و همین موضوع برخی قابلیت ها را محدود می کند. FAST Cache و FAST VP روی این نوع Pool اعمال نمی شود و طراحی باید بدون تکیه بر آن ها انجام شود.
در عوض، قابلیت هایی مثل Compression و کارایی بالاتر Snapshot/Replication جایگاه مهمی در طراحی پیدا می کنند.
Compression، Snapshot و Replication
Compression فقط در All-Flash پشتیبانی می شود و این نکته برای طراحی ظرفیت و برنامه ریزی رشد اهمیت دارد. Snapshot و replication در All-Flash با کارایی بالاتر اجرا می شود و برای سناریوهای حفاظت داده ارزش عملی دارد. این مزیت ها زمانی بهترین نتیجه را می دهد که انتخاب Pool از ابتدا دقیق باشد و توسعه ظرفیت باعث افت شدید flash ratio نشود.
Hybrid Pool
Hybrid Pool معمولاً نسبت به All-Flash ظرفیت بیشتری با هزینه کمتر ارائه می دهد، اما performance کلی پایین تر و response time بالاتری دارد. این نوع Pool برای applicationهایی مناسب است که به response time پایینِ دائمی نیاز ندارند یا حجم زیادی داده عمدتاً inactive دارند. برای Hybrid Pool، توصیه های مشخصی درباره Flash tier و نسبت ظرفیت فلش مطرح شده است.
ترکیب Flash و non-Flash
Hybrid Pool ترکیبی از Flash و non-Flash Driveها است و می تواند تا سه Tier داشته باشد: Extreme Performance، Performance و Capacity. در Hybrid Poolها توصیه می شود در هر Tier از یک drive speed واحد، یک اندازه واحد و یک RAID width واحد استفاده شود. همه drive typeهای پشتیبانی شده می توانند در Hybrid باشند، به جز SAS Flash 4 که باید در All-Flash Pool باشد.
نقش Flash tier در بهبود performance
توصیه شده در Hybrid Pool یک Flash tier provision شود تا performance Pool بهتر شود و هنگام استفاده از data reduction و snapshot یا replication، response time بهبود پیدا کند. برای فعال کردن data reduction، حداقل Flash capacity پیشنهادی برابر 10% ظرفیت Pool است. اگر هدف فقط بهبود performance باشد، 5% Flash هم به عنوان حداقل پیشنهاد شده و افزایش Flash tier می تواند بخش بیشتری از active dataset را روی Flash نگه دارد.
گسترش ظرفیت ( Pool (Expansion
توسعه ظرفیت یکی از مراحل پرتکرار در چرخه عمر Storage است و روش expand در Dynamic و Traditional تفاوت جدی دارد. متن، هم قواعد کلی expand را گفته و هم استثناها و thresholdهای داخلی را توضیح داده است. این بخش کمک می کند expand به شکلی انجام شود که سیستم سریع تر فضا را در دسترس قرار دهد و محدودیت ها رعایت شود.
expand در Dynamic Pool
Dynamic Pool معمولاً بر اساس ظرفیت موردنظر expand می شود و الزام همیشگی به مضرب های RAID stripe width به علاوه یک وجود ندارد. برای مثال، در RAID 5 ممکن است به جای شش Drive، دو Drive هم اضافه شود.
اگر هنگام expand یک drive type جدید اضافه شود، باید حداقل تعداد Drive موردنیاز برای RAID configuration انتخاب شده رعایت شود و در برخی thresholdهای داخلی، سیستم تعداد Drive لازم را اعلام می کند.
expand در Traditional Pool
Traditional Pool با اضافه کردن Drive به Tierهای موجود، اضافه کردن Tier جدید که Driveهای available دارد، یا ترکیبی از هر دو expand می شود. هنگام اضافه کردن Drive، باید آن ها را در مضرب های RAID stripe width انتخاب شده اضافه کرد. در یک مثال عملی داخل متن، برای ( RAID 5 (4+1 حداقل 5 Drive باید اضافه شود و این موضوع حداقل ظرفیت قابل افزودن را مشخص می کند.
محدودیت ها و thresholdهای RAID
در Dynamic Pool، expand با مضرب هایی از RAID stripe width به علاوه یک می تواند باعث شود فضا سریع تر در دسترس قرار گیرد. RAID stripe width از تب RAID در properties همان Pool قابل مشاهده است.
در Traditional هم الزام مضرب ها وجود دارد و در برخی مدل ها، محدودیت هایی مانند عدم امکان expand All-Flash Pool شامل SAS Flash 4 با اضافه کردن SAS یا NL-SAS ذکر شده است.
Best Practiceهای طراحی و نگهداری Pool
بهترین روش ها در متن به شکل مستقیم آمده و بیشتر روی کاهش پیچیدگی، تفکیک منطقی workload و نگهداری ظرفیت آزاد تأکید دارد. این توصیه ها اگر از ابتدا اجرا شود، هشدارها و محدودیت های عملیاتی کمتر رخ می دهد.
کاهش تعداد Poolها
استفاده از Poolهای کمتر، پیچیدگی را کاهش می دهد و انعطاف پذیری را افزایش می دهد. با این حال، ممکن است مناسب باشد چند Pool پیکربندی شود تا workloadهایی با I/O profile متفاوت جدا شوند یا Resourceها برای هدف های مشخص performance اختصاصی شوند. تفکیک برای multitenancy و کوچک تر کردن failure domain هم به عنوان دلیل های قابل دفاع برای چند Pool مطرح شده است.
مدیریت free capacity
Pool برای عملکرد صحیح باید free capacity را حفظ کند. به صورت پیش فرض، اگر free capacity کمتر از 30% باشد، سیستم alert صادر می کند. اگر free capacity کمتر از 5% شود، سیستم به طور خودکار snapshotها و replication sessionها را invalid می کند.توصیه شده است Pool همیشه حداقل 10% free capacity داشته باشد تا رفتارهای ناخواسته رخ ندهد.
تفکیک workloadها
در Best Practice گفته شده جداسازی workloadها با I/O profile متفاوت می تواند مفید باشد. همچنین تخصیص Resourceها به صورت اختصاصی برای رسیدن به هدف های performance، یک دلیل عملی برای طراحی چند Pool است. در Traditional Hybrid Poolها هم پیشنهاد شده Poolهایی که FAST Cache در آن ها فعال است از Poolهایی که فعال نیست جدا شوند.
جمع بندی
پایان خوشِ کانفیگ Pool؛ با تصمیم های قابل توسعه
Storage Pool، Dynamic Pool، Traditional Pool، Unity All-Flash model و Hybrid Pool در این مقاله به شکلی چیده شد که انتخاب Pool و منطق پیکربندی آن روشن باشد. نتیجه مهم این است که قبل از ساخت Storage Resource باید Pool آماده باشد، چون shrink ممکن نیست و تغییر ویژگی ها معمولاً به حذف وابستگی ها گره می خورد. با شناخت تفاوت Dynamic و Traditional در RAID، spare و expansion، مسیر طراحی ساده تر می شود و نگهداری free capacity و انتخاب Tierها هم نقش کلیدی در پایداری performance دارد. همین چارچوب، پایه ای می سازد که در مقالات بعدی دستور کانفیگ، تصمیم ها روی آن سوار شود و ادامه مسیر، منظم و قابل تکرار پیش برود.
برای دریافت مشاوره تخصصی در این زمینه، میتوانید از طریق صفحه «ارتباط با ما» با کارشناسان آکو در ارتباط باشید.
HPE
DELL
Broadcom