Осигуряването на стабилен и същевременно високоефективен сторидж в облака е едно от най-големите предизвикателства в областта на хардуера и софтуера при бързото разрастване на информационния облак. Лошата производителност на сторидж решенията на много водещи облачни компании (IaaS) е едно от най-цитираните оплаквания на потребителите. В този пост ще очертая доминиращия подход за съхранение в момента, нашия настоящ подход, както и какво е бъдещето за съхранение в облака. Добрата новина е, че революцията в технологиите на съхраняване и достъпване данните е точно зад ъгъла!
Както посочих в последната ми публикация относно равняване на облачните сървъри наред с представянето на мрежата, производителността на съхранение на данните е един от ключовите диференциращи фактори между различните IaaS облаци. Ефективността на съхранението варира значително в различните облачни решения и дори в рамките на един и същи с течение на времето. Докато сигурното и надеждно управление на процесора, RAM и мрежовата защита са до голяма степен разрешени, то това не се отнася до сигурното съхранение на данни.
Ключовият компромис при сториджа се прави между производителност и надеждност. Колкото по-надеждно е решението за съхранение, толкова по-бавно е изпълнението, тъй като всяко действие за писане отнема време да бъде дублирано по начин, който не е необходим при по-малко надеждните решения (т.е. такива с по-малко репликации). Например съхраняването на данни в RAID1 дава много по-висока производителност от RAID5 или RAID6. Ако едно устройство в RAID1 се счупи, всички данни на работещото такова са изложени на риск докато не бъде възстановено второто устройство (същото важи и за RAID5). Това не е случаят при RAID6, но пък затова RAID6 има много по-малко ефективност.
Също така е важно да се различава между постоянно и временно съхранение на данни в облака. При временното съхранение, където не става дума за критични данни, не е фатално да има малък временен проблем с хардуера. При постоянното съхранение обаче устойчивостта и надеждността са критични фактори.
Митът за защитения от срив SAN
Повечето публични облаци използват архитектурата на SAN за постоянно съхранение. Тя е ярък свят на корпорациите и изпитан метод за съхранение. Модерните SAN предлагат висока степен на надеждност и значителна вградена резерва за съхраняваните данни. Те включват гранулирано ниво на контрол за това как се съхраняват и възпроизвеждат данните. Накратко, модерният SAN е голямо, високо-усъвършенствано и скъпо оборудване за съхранение, което също така е много сложно и защитено.
Много съвременни потребители на SAN твърдят, че са защитени от срив, но за съжаление практическата действителност изглежда не показва това. Някои от най-големите сривове в облака са свързани с неуспех на SAN или със значителна деградация в производителността му. Сривовете не са чести, но когато това се случи, грешките са огромни. Не само това, но тяхната сложност и собствена природа означават, че когато нещата се объркат имате доста голям и сложен проблем за оправяне. Затова ако има прекъсвания, те често се измерват в часове, а не в минути. Дори и след като проблемът е бил отстранен, самият размер на SAN води до по-дълго време за възстановяване.
Защо тогава просто да не използвате SAN с резерва? По принцип това може да се направи и често се практикува за критично важни данни. На практика обаче в сектора на публичния облак, който е чувствителен към ценовото равнище, не се използва напълно надежден SAN строидж, защото това би довело до цени в пъти по-високи от сегашните.
Съществува и друг проблем със SAN сторидж в облакa и това е латентността. Времето, за което данните преминават през SAN и мрежата, за да достигнат до изчислителните възли, където процесорите вършат цялата работа, е от съществено значение за ефективността. Проблемът не е в трафика, а във времето на изчакване. Именно времето, необходимо за преместване на данните между процесорите и SAN, е причината SAN сториджа да има максимално ниво на производителността.
По наше мнение използването на SAN сторидж e старо решение на нов проблем, затова ние не смятаме използването му в облака за уместно. Ако облакът има за цел да пред;ага надежден и гъвкав сторидж с висока производителност, то следва да се търсят решения отвъд SAN.
Нашият подход: Харесваме прости проблеми с дребни последици
При изграждането на нашия облак още от самото началото взехме решение, че предпочитаме да имаме по-чести проблеми с по-малки последици, отколкото по-редки проблеми със огромни последици. По същество предпочитаме да решим един прост малък проблем, който се появява по-често (но все още рядко), отколкото сложен голям проблем, който може да се среща по-рядко, но отнема доста по-дълго време да бъде разрешен. Поради тази причина решихме да не използваме SAN за съхранението си, а RAID6 масиви във всеки изчислителен възел (compute node).
Чрез интегрирането на локално съхранение на всеки възел, където се извършва изчислителната обработка, в повечето случаи виртуалният диск и процесорът се свързват със същата физическа машина. Това води до много по-малко забавяне на работата на нашия сторидж. Ние обвързахме това с RAID6, за да бъде по-устойчив продуктът. За да предотвратим проблеми с производителността, използваме хардуерни RAID контролери от висок клас с кеш RAM. Нашите RAID контролери са в състояние да доставят висока производителност дори и при RAID6 масиви и са устойчиви на сривове в електрозахранването (за всеки случай нашите изчислителни възли са свързани към две независими захранвания).
За допълнително повишаване на производителността и намаляване на последиците при срив на системата, използваме малки 2.5″ 500GB дискове. Ако някой диск от масива се провали, бързо го заменяме и масивът RAID се възстановява в много по-кратък период от време. Освен това по-голямата плътност на шпиндели на терабайт за съхранение води до това натоварването от интензивния достъп до сториджа е разпределено върху по-голям брой дискове. Това са причините ефективността ни за съхранение да е една от най-високите.
Локалният сторидж има един основен недостатък. Ако физическият хост, на който е диска, по някаква причина се срине, ще загубите достъп до този диск. В действителност хостовете рядко се сриват по този начин (все още не ни се случвало) и поддържаме “горещи резервни части”, които ни позволяват да сменим дисковете почти незабавно, като минимизираме времето на прекъсване до 10-15 минути. Повечето от нашите клиенти имат няколко сървъра на различни физически машини. Това означава, че неуспехът на който и да е хост оказва минимално влияние върху облака като цяло. Той не засяга повечето клиенти и засегнатите от тях имат ограничено прекъсване само на част от тяхната инфраструктура. Сравнете това със срив на SAN като сложност и време за възстановяване!
Въпреки това би било чудесно, ако дори срив на хост не води до загуба на достъп до устройствата, които се намират на него. Също така би било чудесно да имате дискове без ограничения на максималния размер, дори по-големи от размера на всеки един физически хост.
Краят на SAN и локалния сторидж – нов подход
Ясно е, че SAN и локалният сторидж си имат своите недостатъци. За нас недостатъците на локалния сторидж са много по-малко от тези на SAN. В съчетание с по-висока производителност, локалният сторидж със сигурност е правилният избор за публичен облак до момента. Обаче сегашният начин за съхранение на данни скоро ще бъде изместен от нов подход, наречен репликирани блокови устройства (DRBD) или просто “разпределено блоково съхранение на данни”. Ние планираме да използваме този подход в нашия облак.
DRBD приема всеки локален масив за съхранение и – по подобен начин, по който RAID комбинира множество устройства в един единствен масив – комбинира всеки възел за съхранение или изчисляване в един широк матричен облак. За разлика от SAN, управлението на DRBD е обединено, така че няма зависимост от една единствена точка на срив в слоя за управление. По същия начин всички данни, съхранени в който и да е възел, се репликират напълно в други възли. Ако някой физически сървър се срине, няма да има загуба на достъп до данните, съхранявани на него. DRBD означава, че другите виртуални сървъри ще имат достъп до други физически сървъри в масива.
Ако виртуалната ви машина е на хост, който се е сринал (при което бихте загубили изчислителните CPU и RAM ресурси, които сте използвали), нашата система просто ще я върне на друг хост. Очакваме цената на този вид решение за съхранение да не бъде по-висока от досегашните ни цени за сторидж.
Друго голямо предимство на DRBD е възможността да се създават snapshots на дискове, дори ако самите дискове се използват активно от виртуален сървър (така наречените live snapshots). Възстановяването на предишни версии също е възможно. Накратко, благодарение на удобството на snapshots резервните копия се въвеждат в системата посредством репликация.
Има редица решения с отворен код, понастоящем в процес на разработка, които се стремят да създадат DRBD система за сторидж. Един от водещите претенденти в момента е проект, наречен Sheepdog. В рамките на 6 месеца се очаква да бъде налице стабилно решение за DRBD с отворен код.
Компанията Amplidata вече е стартирала изключително здраво, рентабилно разпределено решение за DRBD, което предоставя предимствата, описани по-горе. Също като нас те са финалисти на TechTour и бяха представени на събитието събитието TechTour Cloud и ICT 2.0 в Лозана и CERN през миналата седмица. Презентацията им беше доста интересна.
Разпределяне на натоварването
руго предимство на DRBD е способността да разпредели в множество масиви натоварването на виртуалния диск с интензивна употреба. Докато сегашните решения за локален сторидж разпределят натоварването на даден диск само в един RAID масив, DRBD разпределя натоварването в множество отделни дискови масиви. Резултатът е, че дисковете с тежка употреба имат много по-незначително въздействие върху другите потребители, тъй като тяхното натоварване е разпределено.
Основният урок тук е, че в бъдеще съхранението в облака ще бъде в състояние да осигури много по-надеждно и по-малко променливо ниво на производителност. Това ще направи много клиенти щастливи, които понастоящем страдат от сериозни колебания в качеството на работа на диска.
Латентността става отново критична
Говорих за латентността при SAN сторидж и как това може да се избегне с локален сторидж като се разпределя сториджа в цял набор от отделни физически машини. Въпросът е дали DRBD няма да страда от същия проблем. По принцип да. Ето защо мрежата за съхранение на облака трябва да бъде преразгледана във връзка с реализацията на DRBD.
В момента нашата мрежа за съхранение е със сравнително нисък трафик, почти всички виртуални сървъри са закачени на същата физическа машина като диска. Това означава, че трафикът между физическите сървъри е минимален и латентността е много ниска. До момента говорим за трафик, който е генериран от движението на данни между устройствата за съхранение. Как да се справим с този трафик? Отговорът е да преминем към мрежа с ниска латентност и да увеличим размера на кеша на всеки физически сървър. В това отношение има две основни опции – 10Gbps Ethernet или Infiniband. И двете имат предимства и недостатъци, но и двете споделят обещанието за значително по-ниска латентност в своите мрежи. Тази тема сама по себе си заслужава отделен блог пост!
За да се постигне надеждно съхранение с висока производителност, разпределеното блоково хранилище трябва да бъде реализирано с мрежа за съхранение с ниска латентност.
Къде се вписва SSD?
Solid State Drive (SSD) е идеално решение за съхранение на данни, което има високо съотношение четене / запис. Единствено не е подходящо за приложения за записване на данни, тъй като в това отношение е надминато от много традиционни решения за съхранение. Понастоящем цената на SSD ограничава употребата му при ежедневни нужди за съхранение. Има резон в това, интензивно четени данни да се поместват на SSD, за да се подобри цялостната производителност. Нашата компания полага усилия интензивно да проучи това. Solidfire се канят да предложат елегантно решение за съхранение на данни посредством SSD.
Заключение
Понастоящем има още какво да се желае от съхранението на данни в облака. Напредъкът на DRBD ще достави както удобството и надежността на SAN, така и ефективността на локалния сторидж. Елиминирането на слабите точки в съхранението на данни е огромен скок и ни приближава към една зряла, достъпна и високонадеждна облачна инфраструктура.
- Наръчник за използване на CGroups в облака - юли 10, 2017
- Бъдещето на Cloud Storage (и какво не е наред с настоящето) - юли 10, 2017