Здравейте всички! С тази статия AERODISK отваря блог на Habré. Ура, другари!
Предишни статии на Habré обсъждаха въпроси относно архитектурата и основната конфигурация на системите за съхранение. В тази статия ще разгледаме въпрос, който не е бил разглеждан досега, но често се задава - за устойчивостта на грешки на системите за съхранение AERODISK ENGINE. Нашият екип ще направи всичко възможно системата за съхранение AERODISK да спре да работи, т.е. счупи го.
Случи се така, че на Хабре вече висят статии за историята на нашата компания, за нашите продукти, както и пример за успешно внедряване, за което Благодарим много на нашите партньори - компаниите TS Solution и Softline.
Ето защо тук няма да тренирам умения за управление на копиране и поставяне, а просто ще предоставя връзки към оригиналите на тези статии:
И аз искам да споделя добри новини. Но ще започна, разбира се, с проблема. Ние, като млад доставчик, наред с другите разходи, постоянно се сблъскваме с факта, че много инженери и администратори просто не знаят как да управляват правилно нашата система за съхранение.
Ясно е, че управлението на повечето системи за съхранение изглежда приблизително еднакво от гледна точка на администратор, но всеки производител има свои собствени характеристики. И ние не сме изключение тук.
Ето защо, за да опростим задачата за обучение на ИТ специалисти, решихме да посветим тази година на безплатно обучение. За да направим това, в много големи градове на Русия откриваме мрежа от центрове за компетентност AERODISK, в които всеки заинтересован технически специалист може да премине курс абсолютно безплатно и да получи сертификат за администриране на системи за съхранение на AERODISK ENGINE.
Във всеки център за компетентност ще инсталираме пълноценен демо стенд от системата за съхранение AERODISK и физически сървър, на който нашият преподавател ще провежда присъствено обучение. Графикът на работа на центровете за компетентност ще публикуваме при появата им, но вече открихме център в Нижни Новгород, следва град Краснодар. Можете да се запишете за обучение, като използвате връзките по-долу. Ето известната към момента информация за градове и дати:
- Нижни Новгород (ВЕЧЕ ОТВОРЕНО – можете да се регистрирате тук );
До 16 април 2019 г. можете да посетите центъра по всяко работно време, а на 16 април 2019 г. ще бъде организирано голямо обучение. - Краснодар (СКОРО ОТВАРЯНЕ - можете да се запишете тук );
От 9 април до 25 април 2019 г. можете да посетите центъра по всяко работно време, а на 25 април 2019 г. ще бъде организирано голямо обучение. - Ekaterinburg (СКОРО ОТВАРЯНЕ, следете информацията на нашия уебсайт или на Хабре);
май-юни 2019 г. - Новосибирск (следете информацията на нашия уебсайт или на Хабре);
октомври 2019 г. - Красноярск (следете информацията на нашия уебсайт или на Хабре);
ноември 2019 г.
И, разбира се, ако Москва не е далеч от вас, тогава по всяко време можете да посетите нашия офис в Москва и да преминете подобно обучение.
Всичко. Свършихме с маркетинга, да преминем към технологиите!
На Habré редовно ще публикуваме технически статии за нашите продукти, тестове за натоварване, сравнения, характеристики на употреба и интересни реализации.
Краш тестове на система за съхранение AERODISK ENGINE N2, тест за якост
ВНИМАНИЕ! След като прочетете статията, можете да кажете: добре, разбира се, продавачът ще провери себе си, така че всичко да работи „с гръм и трясък“, парникови условия и т.н. Ще отговоря: нищо подобно! За разлика от нашите чуждестранни конкуренти, ние се намираме тук, близо до вас и винаги можете да дойдете при нас (в Москва или във всеки Централен комитет) и да тествате нашата система за съхранение по всякакъв начин. Следователно няма много смисъл да коригираме резултатите към идеална картина на света, защото Ние сме много лесни за проверка. За тези, които ги мързи да отидат и нямат време, можем да организираме дистанционно тестване. Имаме специална лаборатория за това. Свържете се с нас.
АЧТУНГ-2! Този тест не е тест за натоварване, т.к тук ни интересува само толерантността към грешки. След няколко седмици ще подготвим по-мощен стенд и ще проведем тестове за натоварване на системата за съхранение, като публикуваме резултатите тук (между другото, заявки за тестове се приемат).
Така че, нека да го разбием.
изпитателен стенд
Нашата стойка се състои от следния хардуер:
- 1 x Aerodisk Engine N2 система за съхранение (2 контролера, 64GB кеш, 8xFC порта 8Gb/s, 4xEthernet порта 10Gb/s SFP+, 4xEthernet порта 1Gb/s); В системата за съхранение са инсталирани следните дискове:
- 4 x SAS SSD дискове 900 GB;
- 12 x SAS 10k дискове 1,2 TB;
- 1 x Физически сървър с Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC порта 8Gb/s, 2xEthernet порта 10Gb/s SFP+);
- 2 x SAN 8G суич;
- 2 x LAN 10G суич;
Свързахме сървъра към системата за съхранение чрез превключватели чрез FC и 10G Ethernet. Схемата на стойката е по-долу.
Компонентите, от които се нуждаем, като MPIO и iSCSI инициатор, са инсталирани на Windows Server.
Зоните са конфигурирани на FC комутаторите, съответните VLAN са конфигурирани на LAN комутаторите и MTU 9000 е инсталиран на портовете за съхранение, комутаторите и хоста (как да направите всичко това е описано в нашата документация, така че няма да описваме този процес тук).
Методология на теста
Планът за краш тест е както следва:
- Проверка на повреда на FC и Ethernet портове.
- Проверка на прекъсване на захранването.
- Проверка на повреда на контролера.
- Проверка за повреда на диска в група/пул.
Всички тестове ще се извършват при условия на синтетично натоварване, което ще генерираме от програмата IOMETER. Успоредно с това ще извършим същите тестове, но при условия на копиране на големи файлове в системата за съхранение.
Конфигурацията на IOmeter е както следва:
- Четене/Писане – 70/30
- Блок – 128k (решихме да измием системите за съхранение в големи блокове)
- Брой нишки - 128 (което е много подобно на продуктивното натоварване)
- Пълен произволен
- Брой работници – 4 (2 за FC, 2 за iSCSI)
Тестът има следните цели:
- Уверете се, че процесът на синтетично зареждане и копиране няма да прекъсне или да причини грешки при различни сценарии на повреда.
- Уверете се, че процесът на превключване на портове, контролери и т.н. е достатъчно автоматизиран и не изисква действия на администратора в случай на повреди (т.е. по време на отказ, не говорим за отказ, разбира се).
- Уверете се, че информацията в регистрационните файлове се показва правилно.
Подготовка на хост и система за съхранение
Конфигурирахме блокиран достъп в системата за съхранение, използвайки FC и Ethernet портове (съответно FC и iSCSI). Момчетата от TS Solution описаха подробно как да направите това в предишна статия (). И, разбира се, никой не е отменил ръководствата и курсовете.
Създадохме хибридна група, използвайки всички дискове, които имахме. 2 SSD диска бяха добавени към кеша, 2 SSD диска бяха добавени като допълнителен слой за съхранение (онлайн ниво). Групирахме 12 SAS10k диска в RAID-60P (троен паритет), за да проверим повредата на три диска в групата наведнъж. Остана един диск за автозамяна.
Свързахме два LUN (един през FC, един през iSCSI).
Собственикът на двата LUN е контролерът Engine-0
Да започнем теста
Активираме IOMETER с конфигурацията по-горе.
Записваме пропускателна способност от 1.8 GB/s и латентност от 3 милисекунди. Няма грешки (общ брой грешки).
В същото време от локалния диск „C“ на нашия хост паралелно започваме да копираме два големи файла от 100 GB към FC и iSCSI LUN за съхранение (устройства E и G в Windows), използвайки други интерфейси.
По-горе е процесът на копиране в LUN FC, по-долу в iSCSI.
Тест #1: Деактивиране на I/O портове
Приближаваме системата за съхранение отзад))) и с леко движение на ръката изваждаме всички FC и Ethernet 10G кабели от контролера Engine-0. Сякаш минава чистачка с моп и решава да измие пода точно там, където лежат сополите и кабелите (т.е. контролерът все още работи, но I/O портовете са мъртви).
Нека да разгледаме IOMETER и копирането на файлове. Пропускателната способност падна до 0,5 GB/s, но бързо се върна на предишното си ниво (за около 4-5 секунди). Няма никакви грешки.
Копирането на файлове не е спряло, има спад в скоростта, но не е никак критичен (от 840 MB/s падна на 720 MB/s). Копирането не е спряло.
Преглеждаме регистрационните файлове на системата за съхранение и виждаме съобщение за липсата на портове и автоматичното преместване на групата.
Информационният панел също ни казва, че не всичко е много добре с FC портовете.
Системата за съхранение оцеля при отказ на I/O портове успешно.
Тест № 2. Деактивиране на контролера за съхранение
Почти веднага (след като включихме кабелите обратно в системата за съхранение) решихме да довършим системата за съхранение, като извадихме контролера от шасито.
Отново се приближаваме към системата за съхранение отзад (хареса ни))) и този път изваждаме контролера Engine-1, който в този момент е собственик на RDG (към който се премести групата).
Ситуацията в IOmeter е следната. I/O спря за около 5 секунди. Грешките не се натрупват.
След 5 секунди I/O се възобнови с приблизително същата производителност, но със закъснения от 35 милисекунди (закъсненията се коригират след около няколко минути). Както може да се види от екранните снимки, стойността на общия брой грешки е 0, тоест няма грешки при писане или четене.
Нека да разгледаме копирането на нашите файлове. Както можете да видите, не беше прекъснато, имаше лек спад в производителността, но като цяло всичко се върна на същото ~ 800 MB/s.
Отиваме в системата за съхранение и виждаме проклятие в информационния панел, че контролерът Engine-1 е недостъпен (разбира се, ние го убихме).
Виждаме също подобен запис в регистрационните файлове.
Контролерът за съхранение също оцеля при повреда успешно.
Тест № 3: Изключване на захранването.
За всеки случай започнахме отново да копираме файлове, но не спряхме IOMETER.
Издърпваме захранващия блок.
Добавен е още един сигнал към системата за съхранение в информационния панел.
Също така в менюто на сензорите виждаме, че сензорите, свързани с изваденото захранване, са станали червени.
Системата за съхранение продължава да работи. Повредата на захранващия блок по никакъв начин не засяга работата на системата за съхранение; от гледна точка на хоста скоростта на копиране и индикаторите IOMETER остават непроменени.
Тестът за прекъсване на захранването премина успешно.
Преди последния тест решихме да върнем малко към живота системата за съхранение, да върнем обратно контролера и захранващия блок, а също така да подредим кабелите, за което системата за съхранение щастливо ни информира със зелени икони в своя здравен панел .
Тест № 4. Повреда на три диска в група
Преди този тест извършихме допълнителна подготвителна стъпка. Факт е, че системата за съхранение на ENGINE предоставя много полезно нещо - различни политики за възстановяване. TS Solution писа за тази функция по-рано, но нека си припомним нейната същност. Администраторът на хранилището може да посочи приоритета за разпределяне на ресурси по време на повторното изграждане. Или в посока I/O производителност, тоест възстановяването отнема повече време, но няма намаляване на производителността. Или в посока на скоростта на възстановяване, но производителността ще бъде намалена. Или балансиран вариант. Тъй като производителността на съхранението по време на възстановяването на дисковата група винаги е главоболие на администратора, ние ще тестваме политика с пристрастия към I/O производителността и за сметка на скоростта на възстановяване.
Сега нека проверим за повреда на диска. Също така разрешаваме запис в LUN (файлове и IOMETER). Тъй като имаме група с троен паритет (RAID-60P), това означава, че системата трябва да издържи на повреда на три диска и след повреда трябва да работи автоматичната подмяна, един диск трябва да заеме мястото на един от повредените в РДГ и от него трябва да започне възстановяването.
Започнете. Първо, чрез интерфейса за съхранение, нека маркираме дисковете, които искаме да извадим (за да не пропуснем и да издърпаме диска за автоматична смяна).
Проверяваме индикацията на хардуера. Всичко е наред, виждаме три маркирани диска.
И изваждаме тези три диска.
Нека да видим какво има на хоста. И там... нищо особено не се случи.
Индикаторите за копиране (по-високи са отколкото в началото, защото кеша е загрял) и IOMETER не се променят много при премахване на дисковете и стартиране на възстановяване (в рамките на 5-10%).
Нека да разгледаме какво има в системата за съхранение.
В състоянието на групата виждаме, че процесът на преструктуриране е започнал и е близо до завършване.
В скелета на RDG се вижда, че 2 диска са в червен статус, а единият вече е сменен. Дискът за автоматична замяна вече не е там; той замени третия повреден диск. Възстановяването отне няколко минути, записването на файлове при повреда на 3 диска не беше прекъснато и I/O производителността не се промени много.
Тестът за повреда на диска определено премина успешно.
Заключение
На този етап решихме да спрем насилието срещу системите за съхранение. Нека обобщим:
- Проверка на повреда на FC порт - успешна
- Проверка на грешка на Ethernet порта - успешна
- Проверка на повреда на контролера - успешна
- Тест за прекъсване на захранването - Успешен
- Проверка на повреда на диска в grouppool - успешно
Никоя от повредите не спира записа или причинява грешки в синтетичното натоварване; разбира се, имаше удар в производителността (и ние знаем как да го преодолеем, което скоро ще направим), но като се има предвид, че това са секунди, това е напълно приемливо. Заключение: устойчивостта на грешки на всички компоненти на системата за съхранение AERODISK работи на ниво, няма точки на повреда.
Очевидно в една статия не можем да тестваме всички сценарии на повреда, но се опитахме да покрием най-популярните. Затова, моля, изпращайте вашите коментари, предложения за бъдещи публикации и, разбира се, адекватна критика. Ще се радваме да обсъдим (или още по-добре, елате на обучението, дублирам графика за всеки случай)! До нови тестове!
- Нижни Новгород (ВЕЧЕ ОТВОРЕНО – можете да се регистрирате тук );
До 16 април 2019 г. можете да посетите центъра по всяко работно време, а на 16 април 2019 г. ще бъде организирано голямо обучение. - Краснодар (СКОРО ОТВАРЯНЕ - можете да се запишете тук );
От 9 април до 25 април 2019 г. можете да посетите центъра по всяко работно време, а на 25 април 2019 г. ще бъде организирано голямо обучение. - Ekaterinburg (СКОРО ОТВАРЯНЕ, следете информацията на нашия уебсайт или на Хабре);
май-юни 2019 г. - Новосибирск (следете информацията на нашия уебсайт или на Хабре);
октомври 2019 г. - Красноярск (следете информацията на нашия уебсайт или на Хабре);
ноември 2019 г.
Източник: www.habr.com