پیام فرستادن
تماس با ما
LEO

شماره تلفن : 13486085502

مهاجرت معکوس Dropbox ، از ابر تا مراکز داده شخصی ، پنج سال بعد

July 23, 2020

"بالابر سنگین و تمایز نیافته."اینگونه است که خدمات وب آمازون کارهایی را که بطور معمول توسط ادارات IT در مراکز داده های سازمانی از زمان راه اندازی سرویس ابری عمومی خود انجام می شود ، مشخص کرده است.

به ابر بروید و "شما باید از این منابع کمیاب - مهندسان توسعه نرم افزار خود استفاده کنید - و به جای اینکه آنها را بر روی بلند کردن سنگین و تمایز نیافته زیرساخت ها کار کنید ، می توانید روی آنچه که تجارت شما را متمایز می کند ، کار کنید." شرکت او در سال 2015 دوباره: کلید واژه های اختراع."و سپس شما می توانید برنامه خود را در زیرساخت های جهانی مستقر کنید."

در اوایل همان سال ، Dropbox - یک سرویس ذخیره سازی ابری که در AWS تأسیس شده است - راه اندازی شد تلاش برای حرکت جهت دیگر.این زمان پیش بینی کرد که با وجود قول های جسی مبنی بر اینکه منابع آمازون به طور مؤثر نامتناهی است ، دیگر نمی تواند خدمات خود را در همگام سازی با تقاضای مشتری مقیاس کند.بین فوریه و اکتبر سال 2015 ، Dropbox با موفقیت 90 درصد از حدود 600 پتابی داده مشتری خود را به شبکه داخلی مراکز داده موسوم به Magic Pocket منتقل کرد.

"از ابتدا برای ما مشخص بود كه ما باید همه چیز را از ابتدا بسازیم." Akhil Gupta در وبلاگ شرکت خود در سال 2016، "از آنجا که هیچ اثری در جامعه منبع باز وجود ندارد که ثابت شود در مقیاس ما قابل اعتماد است.معدود شرکت هایی در جهان همان اندازه ای که ما انجام می دهند ، برای مقیاس ذخیره سازی همان شرایط را دارند. "

بیانیه هایی مانند برخی باعث تحریک معکوس Dropbox به عنوان نوعی واقعه یک طرفه شد.Dropbox برخلاف شرکت های روزمره در صنعت مانند نفت ، مراقبت های بهداشتی یا بیمه ، علاقه ای به مزایای خدمات مهندسی مستقیم در سیستم خود داشت.حرکت آن به خارج از ابر به عنوان سفری که از آن بقیه دنیای فناوری اطلاعات می توانند هرگونه درس مربوط را بیاموزند ، درک نمی شد.

پنج سال بعد ، بسیاری از سازمان های دیگر ، از جمله سازمان های خارج از صنعت IT ، در حال کشف هستند که محدودیت هایی برای مقیاس پذیری نامتناهی آنها در ابر عمومی وجود دارد.دلایل معتبر برای سفر عاشقانه برای آن وجود دارد که می تواند عاشقانه باشد.اکنون سفر Magic Pocket بیشتر شبیه یک اکسپدیشن پیشگام است.

ویندوز ریز

Dropbox طرحی را ساخت.ما بررسی کردیم که ظرفیت ما چقدر است و پیش بینی می کردیم که رشد ما چه خواهد بود. "طبق معمول ، این تیم مدلی را برای برنامه ریزی ظرفیت مرکز داده ایجاد کرده است.

اینکه Dropbox این تمرین را پشت سر گذاشت ، نباید برای هر کسی که سایتی مانند DCK را به طور مرتب می خواند ، شوک باشد.اما ممکن است رویکرد شرکت به برنامه ریزی ظرفیت امروز یک سورپرایز باشد.تیم گارتسون در پنجره های برنامه ریزی کوتاه و غریب ، که معمولاً شش ماه و حتی سه ماه است ، فعالیت می کند.

وی اعتراف کرد: "این نوعی رویکرد به عقب است."آنها هنوز پیش بینی های رشد سالانه خود را دارند ، اما بر اساس ارتباط با تیم نرم افزاری و زمان سرب پیش بینی شده ، این پیش بینی ها به طور مکرر در طول سال به روز می شوند ("مدت زمان خرید ظرفیت چقدر طول می کشد ، و چه زمانی می توانیم واقعاً ظرفیت زمین را بدست آوریم و در دسترس قرار دهیم. ")

وی ادامه داد: "این کار به کار خود با گروه نرم افزاری ما ادامه می دهد و همه چیز را در داخل Dropbox در داخل ساده می کند: گفت:" امسال چه انتظاری داریم؟ "و یک پیش بینی مدل ظرفیت را انجام دهید که همیشه به روز می شود - ماهانه ، هفتگی ، سه ماهه.تیم مرکز داده همیشه در این فرآیند یکپارچه شده است. "

نرم افزار اول

برای بسیاری از مغازه های فناوری اطلاعات ، استقرار با دستیابی یا ساخت سخت افزار ، تهیه آن ، استقرار آن و سپس ادغام آن در خوشه های خدمات و تزریق آن با نرم افزار آغاز می شود.گرتسون به ما گفت ، رویکرد Dropbox در جهت دیگر کار می کند.تیم نرم افزاری ابتدا پیش بینی های ظرفیت فعال را تجزیه و تحلیل می کند و الگویی را برای سرورهایی ارائه می دهد که به مراکز داده خود در مناطق مختلف شهری نیاز دارند.این توسعه دهندگان مهندسی "کاردستی" را انجام می دهند ، از جمله پیکربندی خدمات و برنامه های سرور.

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

"اهرمهایی که مادر نظر بگیرید زمان ساخت ماست. "ما در سال 2015 با مدت زمان ساخت شش ماه شروع کردیم.ما اکنون آن را به سه ماه منتقل کرده ایم ... ما پیش بینی سالانه را انجام نمی دهیم و از آن نتیجه نمی گیریم.ما سالانه را می گیریم و برنامه ای داریم ، اما این نقاط عطف بحرانی را نیز در اختیار داریم که اگر پیش بینی تغییر کند ، می توانیم آن را تنظیم کنیم ، زیرا ما فقط زمان ساخت سه ماه داریم. "

کنترل زمان های کوتاه تر برای Dropbox راحت تر است.به جای تأخیر در ساخت و ساز بنا به دلایلی غیر منتظره ، می توان آن را فسخ کرد و برنامه جدیدی را در محل خود ، بدون ایجاد اختلال آغاز کرد.با توجه به چگونگی برنامه ریزی ارکسترهای میکروسرویس اجزای نرم افزار توزیع شده - Dropbox متوجه شده است که وقتی به برنامه ای که در همه زمانها قرار دارد و نه جزئی از آن اختصاص دارد ، انعطاف پذیرتر است. یا کاملاً تأخیر

مدیریت ردپای

این تیم تغییرات در تقاضا برای ظرفیت مرکز داده های فیزیکی را در هر یک از سایت های خود از نزدیک مشاهده می کند.آنها در هر زمان معینی موجود در یک پنجره فعلی و هنگامی که ظرفیت جدیدی در دسترس باشد ، می توانند موجودی را به صورت دستی مدل کنند.Dropbox با استفاده از این روش هرگز برای اهداف ظرفیتی در سال بعد برنامه ریزی نمی کند.مانند ساختن دیوار عظیم یک آجر در هر زمان ، فقط روی برنامه های کوتاه مدت تمرکز دارد ، برنامه ریزی برای بیش از شش ماه در یک زمان.

همانطور که در بیشتر مراکز داده با محوریت ذخیره سازی ، چگالی رک در امکانات Dropbox در پنج سال گذشته افزایش یافته است.این امر باعث شده است كه كاهش ردپای آن ، در حالی كه ظرفیت ذخیره سازی مشتری در مقیاس petabyte افزایش می یابد ، كاهش یابد.گرتسون گفت: "اکنون ما می توانیم فضای بدنی کمی بیشتری داشته باشیم.""از کجا می خواهیم برای 100 کابینت برنامه ریزی کنیم ، اکنون می توانیم 30 نفر را برنامه ریزی کنیم."

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