Какво всъщност означава хипермащабното съхранение

Нека бъдем ясни: Хипер скалата не е свързана с това колко си голям.

Организациите не трябва да бъдат огромни, за да използват хипермащабни решения. Но точно това си мислят много ИТ инфраструктура, операции и специалисти по devops, когато за първи път научат за хипер скалата.

Преобладаващото убеждение е, че хипермащабната архитектура е предназначена за изключително големи инфраструктури - като тези, експлоатирани от LinkedIn, Amazon или Netflix - защото тя се мащабира до хиляди екземпляри и петабайта данни. Както се оказва, по-добре е да мислим за хипермащаб като описание на подход, а не за размер . Става въпрос за автоматизация, оркестрация и изграждане на ИТ, които интелигентно се мащабират, когато и когато бизнесът се нуждае от това. Хипермащабните внедрявания могат и трябва да започват от малко, след което да се мащабират за неопределено време. Те също така трябва да ви позволят да мащабирате независимо само частта от инфраструктурата, която се нуждае от нея, което е в противовес на друга нововъзникваща тенденция в центъра за данни на предприятието, хиперконвергенция.

Объркани ли сте вече? Ако е така, не сте сами. Нека се потопим малко по-дълбоко.

Определяне на хиперскала

Концепцията за изграждане на хипермащабна архитектура е помрачена от много тангенциални термини. По-конкретно виждаме клиентите да са объркани относно хиперконвергираната, хипермащабната (или уеб скала), конвергентната, софтуерно дефинирана и базирана на стоки инфраструктура.

Нека отделим малко време, за да изясним определенията на тези термини на съставките:

  • Софтуерно дефиниран: Инфраструктура, при която функционалността е напълно отделена от основния хардуер и е едновременно разширяема и програмна. Прочетете тази публикация за нашата работа по-специално за софтуерно дефинираното хранилище.
  • Базирано на стоки : Инфраструктура, изградена на върха на стокова или индустриална стандартна инфраструктура, обикновено x86 монтиран в багажник или блейд сървър. Както писахме в миналото, не свързвайте стоката с евтина.
  • Converged: Мащабна архитектура, при която компонентите на сървъра, съхранението, мрежата и виртуализацията / контейнеризацията са свързани като предварително тествано, предварително интегрирано решение. Компонентите все още са различни в тази архитектура.
  • Hyperconverged: Мащабна архитектура, която отвежда сближена инфраструктура още една стъпка напред чрез комбиниране на софтуерно дефинирани компоненти върху стоков хардуер, опаковани като едно решение - често един уред. Компонентите вече не са различни.
  • Хиперскала: Архитектура за мащабиране, която също е дефинирана и базирана на стоки, но където сървърът, съхранението, мрежата и ресурсите за виртуализация / контейнеризиране остават отделни. Всеки компонент е различен и може да бъде независимо мащабиран.

В обобщение, помислете за хиперконвергираната инфраструктура като за модерна, логична крайност на конвергентните системи, докато хиперскалата е модерната, логична крайност на това как изграждаме центрове за данни от 30 години. И двете имат смисъл за специфична среда, както е показано по-долу.

Хипер скала и хиперконвергенция

В Hedvig се стремим да предоставим решение за съхранение, което може да бъде гъвкаво пригодено за всяко работно натоварване, от частни облаци, включително Docker и OpenStack, до внедряване на големи данни, работещи с Hadoop или NoSQL, до по-традиционна виртуализация на сървъри, възстановяване при бедствия, архивиране и архивиране. Разпределената платформа за съхранение на Hedvig виртуализира и обединява флаш и въртящ се диск в сървърния клъстер или облак, представяйки го като единична, еластична система за съхранение, която може да бъде достъпна чрез файлови, блокови или обектни интерфейси.

Платформата за разпределено съхранение на Hedvig се състои от три компонента:

  • Услуга за съхранение на Hedvig: Патентован двигател на разпределени системи, който мащабира производителността и капацитета на съхранение с готови x86 и ARM сървъри. Услугата за съхранение на Hedvig може да се изпълнява локално или в публични облаци като AWS, Azure и Google. Той предоставя всички опции за съхранение и възможности, необходими за внедряване в предприятието, включително вградена дедупликация, вградена компресия, моментни снимки, клонинги, тънко осигуряване, автоматично изглаждане и кеширане.
  • Прокси за съхранение на Hedvig: Лек VM или контейнер, който позволява достъп до услугата за съхранение на Hedvig чрез стандартни за индустрията протоколи. Понастоящем Hedvig поддържа NFS за файлове и iSCSI за блок, както и драйвери за OpenStack Cinder и Docker. Hedvig Storage Proxy също така позволява кеширане и дедупликация от страна на клиента с локални SSD и PCIe флаш ресурси за бързо локално четене и ефективен трансфер на данни.
  • API на Hedvig: API на базата на REST и RPC както за съхранение на обекти, така и за операции на Hedvig. Понастоящем Hedvig поддържа Amazon S3 и Swift за съхранение на обекти. Разработчиците и администраторите на ИТ операции могат да използват API за управление, за да позволят достъп до всички функции за съхранение на Hedvig, за да автоматизират осигуряването и управлението с портали за самообслужване, приложения и облаци.

Hedvig поддържа хиперконвергенция, като обединява Hedvig Storage Proxy и Hedvig Storage Service като виртуални уреди, работещи на стоков сървър с хипервизор или контейнерна ОС. За хипермащабиране услугата за съхранение на Hedvig се разполага на голи метални сървъри, за да образува специален слой за съхранение, докато проксито за съхранение на Hedvig се разполага като виртуална машина или контейнер на всеки сървър на изчислителното ниво.

Защо да изберете хипер скала за съхранение

Данните растат далеч по-бързо от бюджетите за съхранение. Икономиката осакатява предприятията, които нямат ресурсите на интернет голиати като Amazon, Google и Facebook. По този начин предприятията трябва да възприемат софтуерно дефинирано и базирано на стоки съхранение, за да намалят разходите и да запазят гъвкавостта и мащабируемостта, необходими за спазване на бизнес изискванията.

В Hedvig забелязахме, че около 80 процента от времето клиентите избират хипермащабна архитектура, а не хиперконвергирана, въпреки факта, че поддържаме и двете. Още по-интересното е, че много от нашите клиенти идват при нас, мислейки точно обратното. Около 80 процента първоначално искат хиперконвергирано решение, но след като изпълнят домашните си, избират хипермащабния подход.

Защо? Накратко, защото те предпочитат гъвкавостта (или гъвкавостта, ако трябва да използвате този термин) преди всичко при архитектурата на тяхната инфраструктура. Помислете за следното:

  • Хиперконвергираната система предлага опростен подход „градивен елемент“ към ИТ. За стройни ИТ организации, които искат да намалят режийните разходи за внедряване и разширяване на облачна инфраструктура, хиперконвергенцията предлага добро решение. Но той изисква относително предсказуем набор от работни натоварвания, където „локалността на данните“ е основен приоритет, което означава, че приложението или VM трябва да бъдат разположени възможно най-близо до данните. Ето защо VDI е плакат за хиперконвергенция. Потребителите искат локалното си „виртуално C: устройство“. Но това не е гъвкаво, тъй като включва мащабиране на всички елементи на стъпка.
  • Хипермащабна система поддържа съхранението независимо от изчисленията, позволявайки на ИТ на предприятието да мащабира капацитета, когато бизнесът изисква. Хипермащабният подход към центъра за данни и облачната инфраструктура предлага високо ниво на еластичност, помагайки на организациите да реагират бързо на променящите се нужди от приложения и съхранение на данни. Това също е архитектура, която по-добре отговаря на съвременните натоварвания като Hadoop и NoSQL, както и тези, създадени с облачни платформи като OpenStack и Docker. Всичко това са примери за разпределени системи, които се възползват от независимо мащабирано споделено хранилище.

Това, което сте имали с нашите клиенти е потвърждение, събиране на това, което сме се отбележи, от известно време: че hyperconverged е един отговор, а не за отговор, когато се проучват модерна архитектура за съхранение. Разбира се, индустрията вижда голямо махало, което се люлее към хиперконвергиране поради своята простота. Но ако вашите данни нарастват експоненциално и вашите нужди за изчисления не са, тогава имате несъответствие на импеданса, което не е подходящо за хиперконвергенция.

Хипер скала или хиперконвергенция?

Hyperconverged може да бъде по-опростен и по-рентабилен подход. Това, което нашите клиенти откриват с Hedvig, е, че ние поддържаме функция, която прави хипер скалата подходяща за почти всички натоварвания: кеширане от страна на клиента. Hedvig може да се възползва от локалните SSD и PCIe устройства във вашето изчислително ниво, за да изгради кеш за запис. Това значително подобрява производителността на четене и, което е по-важно, решава предизвикателството за местоположението на данните. Съхранението все още е отделено и работи в свой собствен, хипермащабен слой, но приложения, виртуални машини и контейнери могат да се възползват от данните, кеширани локално на изчислителното ниво. Това също решава проблема с това как да увеличите нивото си на кеширане, но това е тема за друга статия.

Като пример за това предимство, един клиент избра хипермащабния подход на Hedvig за VDI, натоварване, традиционно запазено за хиперконвергирани решения, както беше обсъдено по-горе. В този случай клиентът има „мощни потребители“, които изискват 16 vCPU и 32 GB памет, които да бъдат посветени на всеки хостван работен плот. В резултат на това компанията беше принудена да внедри голям брой хиперконвергирани възли, за да поддържа изискванията за обработка и памет, като същевременно ненужно увеличава капацитета за съхранение в Lockstep.

С платформата Hedvig клиентът успя да създаде специални възли за стартиране на фермата Citrix XenDesktop на гъсти блейд сървъри с адекватни CPU и RAM. Данните се съхраняват в отделен хипермащабен клъстер Hedvig на монтирани в багажник сървъри, като данните се кешират обратно на сървърите XenDesktop в локални SSD. Резултатът? Драматично по-евтино решение (60 процента по-малко). По-важното е, че също така осигурява по-гъвкава среда, в която компанията може да се възползва от закона на Мур и да закупи най-мощните сървъри, необходими за надграждане на производителността на работния им плот, без да се налага да надгражда сървърите за съхранение.

Въз основа на нашия опит има няколко лесни правила, за да определите коя архитектура е подходяща за вас.

  • Изберете хиперскала, когато ... вашата организация има 5000 служители или повече, повече от 500 терабайта данни, повече от 500 приложения или повече от 1000 виртуални машини.
  • Изберете хиперконвергирана, когато ... сте под тези номера на воден знак, имате пет или по-малко служители, управляващи вашата виртуална инфраструктура, или сте в отдалечен или клон.

Добрата новина е, че не е задължително да бъде решение или. Можете да започнете в хиперконвергирана среда, след това да преминете към хипер скала или да смесите и съчетаете двете. Нашата философия е, че вашите приложения диктуват кое трябва да използвате. И тъй като нуждите на вашето приложение ще се променят с течение на времето, така и вашето внедряване.

В съвременния бизнес промяната и растежът са задължителни. Все по-често няма начин да се реши тази загадка без хипермащабната архитектура, която уеб гигантите са пионери. Това, което се промени, е, че всяко предприятие вече може да се възползва от хипермащабния подход.

Роб Уайтли е вицепрезидент по маркетинг в Hedvig.

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на [email protected]