Днес в IT инфраструктурата, с широкоразпространеното използване на виртуализацията, системите за съхранение на данни са ядрото, което съхранява всички виртуални машини. Отказът на този възел може напълно да спре работата на изчислителния център. Въпреки че значителна част от сървърното оборудване има резервираност по подразбиране в една или друга форма, именно заради специалната роля на СХД в рамките на дата центъра се предявяват по-високи изисквания към нея относно „живучестта“.
Най-ефективният метод за осигуряване на отказоустойчивост в IT е използването на няколко копия на оборудването и софтуера (в най-простия случай - дублиране). Разбира се, СХД може да бъде напълно дублирана. И за disaster recovery именно такъв подход се използва. Но далеч не всички компании могат да си позволят такова решение. Не става дума само за удвоената цена на оборудването, но и за други разходи, свързани с организирането на подобно решение и неговата поддръжка в бъдеще.
Въпреки това възможността за дублиране на оборудването не отменя необходимостта от осигуряване на отказоустойчивост на нивото на компонентите. По-специално, в СХД се използва резервиране на блоковете захранване, модулите за охлаждане, носителите и, разбира се, контролерите. Всичко това отдавна е станало обичайно. Трудно е да се намери СХД без използване на такъв дизайн. тук - не е изключение. Но в тази статия искаме да говорим за неща, които не са очевидни веднага и които са насочени преди всичко към повишаване на отказоустойчивостта на системата като цяло.
Модулите за охлаждане
Много често в с корпуси 2U-3U се използват комбинирани модули, които обединяват захранващи блокове и вентилатори. От една страна, това е удобно, тъй като трябва да се обслужва само един блок. От друга страна, ако системата за охлаждане се повреди, може принудително да бъде изключен захранващият блок, за да се избегне прегряване. И макар да изглежда, че няма да настъпи критична ситуация, определено не е разумно да се добавят уязвимости на СХД.
Охлаждането в СХД Qsan е организирано под формата на отделни модули с „гореща“ подмяна, независимо от захранващите блокове. В самите захранващи блокове се предвидени собствени вентилатори, предназначени за охлаждане на самите БП. Модулът за охлаждане съдържа два независими вентилатора, които осигуряват резервираност помежду си. В СХД има два такива модула: един вдясно и един вляво – за ефективно охлаждане на всички компоненти. Ако един от вентилаторите се повреди, всички останали автоматично увеличават оборотите си с цел да компенсират образувания недостиг на въздушен поток. Именно затова повредата на вентилатор не представлява опасност от прегряване на целия устройството.
Топология на свързване на разширителни модули
Класическа схема на свързване к СХД представлява топология, наречена каскада. В този случай съответните контролери на модула и СХД се свързват помежду си с един единствен SAS кабел. В крайна сметка получаваме 2 кабела за система с два контролера. Ако е необходимо да се свърже втори модул, той се свързва по същия начин с първия модул. И така нататък. Плюс на тази топология е простота на реализиране в оборудването. Минусът е известна уязвимост при внезапно прекъсване на SAS веригата поради повреда на неподключените помежду си контролери на СХД и модула или поради отсъствие на захранване на един от разширителните модули в средата на веригата. Резултатът ще бъде загуба на достъп до част от дисковете и възможно разпадане на RAID група, ако тя е “разпръсната” по няколко кутии.
От повредите на контролерите, Qsan разполага с защита под формата на вътрешна логическа връзка между контролерите чрез бекплейна на СХД. Т.е. контролерът на СХД вижда не само контролера на JBOD, който е непосредствено свързан с него, но и контролера на „съседа“ чрез специална връзка в бекплейна. В резултат, ако се случи такава ситуация и никой физически не изважда SAS кабелите между СХД и модула, достъпът до всички дискове ще бъде запазен.
За защита от разкъсване на SAS веригата, например, поради възникване на проблем с електричеството на разширителната стойка, обикновено се прилага друга топология на свързване – обратен каскад. В този случай СХД се свързва директно към първата и последната стойка в веригата, получавайки достъп до носителите от двете страни.
Ако търсите по-силна защита, можете да изградите по-мащабни конфигурации, използвайки, например, топология на дърво. Или можете да усложните конфигурацията с комбинация от споменатите топологии. Това е възможно благодарение на голямото количество SAS конектори на устройствата (по 2 на всеки контролер на СХД и по 5 на всеки контролер на JBOD) с автоматично разпознаване на режимите на работа вход/изход. Най-важното е, че самият администратор да не се обърка. А СХД ще може да настрои конфигурацията правилно.
Бързо възстановяване
Наличието на резервни дискове в системата с функция „гореща“ замяна (hot spare) значително повишава надеждността на съхранение на информация. Въпреки това, просто фактът, че подобни дискове са отделени, не означава абсолютна защита. Проблемът е, че процесът на възстановяване (ребилд) е доста трудоемък и често продължителен. Трудоемкостта идва от непрекъснатия достъп до основните данни. Т.е. системата, наред с текущата работа, трябва допълнително да копира данни на новия диск. Продължителността на ребилда пряко зависи от капацитета на носителя и неговите скоростни характеристики. Тъй като системата не знае какво реално заема място на дисковете, по време на ребилда просто копира всичко: блок след блок.
В резултат на това восстановленията на модерен диск с голям капацитет от 10+ТБ при сериозно натоварване на СХД може лесно да отнеме седмица или повече. Също така трябва да имате предвид, че по време на ребилда вероятността за отказ на други носители се увеличава значително поради повишеното натоварване. А това вече може да представлява сериозна опасност при използване, например, на RAID5.
Като решение на този проблем много производители на СХД се фокусираха върху ускоряване на процеса на възстановяване. За това могат да се приложат различни подходи, но основната идея е да се копират само реално заетите блокове при ребилд. Qsan също не остана извън този проблем. При СХД на този вендор с активирана опция системата проследява използваните за запис блокове, като по този начин има възможност при отказ на диска да копира на нов носител само тях.
Опцията Fast Rebuild не е включена по подразбиране при създаването на нови обеми, тъй като нейното използване оказва влияние върху производителността, особено при операции с произволен запис, защото:
- Необходимо е да се проследява записът в блоковете;
- При ребилд не се извършва повторно изчисление на контролни суми за неползваното пространство, затова при нов запис в тази област е нужно първо да я „инициализирате“.
Поради това не се препоръчва да се използва Fast Rebuild за обеми, например, с натоварени бази данни или в системи за видеонаблюдение, където томът все пак в крайна сметка ще бъде запълнен на 100%. Но за файлови или пощенски сървъри тази опция ще бъде много полезна.
Вместо заключение
Всеки производител на СХД предположава, че неговите устройства са надеждни. И ако няма фатални грешки при разработката на устройствата и прекомерно желание за икономии по време на производството и тестването им, може в общи линии да се съгласите с вендора. Въпреки това, трябва да разберем:
- базовата отказоустойчивост на СХД – това е преди всичко начин за продължаване на достъпа до данни в случай на отказ на някой от компонентите;
- допълнителните опции за отказоустойчивост (като тези, описани по-горе) – това е изключване на някои варианти на неисправности и повишаване на шансовете ви да имате достъп до данни;
- 100% надеждност, за съжаление, не съществува. Но за да се приближим максимално до нея, повечето разумни вендори СХД (и включително тях) полагат максимални усилия за безкрайно усъвършенстване на своите продукти както в хардуерната, така и в софтуерната част.
В същото време не бива да забравяте, че никаква абсолютна надеждност на СХД не отменя необходимостта от резервни копия, ясни и репетирани планове за възстановяване в случай на инцидент и оперативна техническа поддръжка от вендора.
Източник: habr.com
