Днес ще говорим за интересна технология, реализирана в СХД Unity/Unity XT, – FAST VP. Ако за първи път чувате за Unity, на връзката в края на статията можете да се запознаете с характеристиките на системата. В проектния екип на Dell EMC работех по FAST VP повече от година. Днес искам да разкажа по-подробно за тази технология и да разкрия някои детайли от нейната реализация. Разбира се, само онези, които мога да разкрия. Ако се интересувате от въпросите на ефективното съхранение на данни или просто не сте напълно разбрали документацията, тази статия определено ще бъде полезна и интересна.
Направо ще кажа какво няма да намерите в материала. Няма да търсим конкуренти и да правим сравнения с тях. Също така не планирам да разказвам за подобни технологии с отворен код, защото любопитният читател вече знае за тях. И, разбира се, не смятам да рекламирам нищо.
Съхранение на слоеве. Цели и задачи на FAST VP
FAST VP се разшифрова като Пълно Автоматизирано Съхранение на Слоеве за Виртуален Пул. Звучи сложно? Нищо, сега ще разберем. Слоевете (tiering) са начин на организация на съхранението на данни, при който има няколко нива, на които се съхраняват тези данни. Всяко от тях притежава свои характеристики. Най-важните: производителност, обем и цена за съхранение на единица информация. Разбира се, между тях съществува взаимовръзка.
Важна особеност на слоевото съхранение е, че достъпът до данните се предоставя еднородно, независимо от нивото на съхранение, в което в момента се намират, а размерът на пула е равен на сумата от размерите на ресурсите, които го съставят. Тук се крият разликите от кеша: размерът на кеша не се добавя към общия обем на ресурса (пулът в този случай), а данните от кеша дублират някакъв фрагмент от данните на основния носител (или ще дублират, ако данните от кеша все още не са записани). Също така разпределението на данните по нива е скрито от потребителя. Тоест, потребителят не вижда какви именно данни са разположени на всяко ниво, въпреки че може да влияе на него косвено чрез задаване на политики (за тях по-късно).
Сега да разгледаме особеностите на реализацията на съхранение на слоеве в Unity. В Unity се отличават 3 нива, или слоя:
- Изключителна производителност (SSD дискове)
- Производителност (SAS HDD 10k/15k RPM)
- Капацитет (NL-SAS HDD 7200 RPM)
Те са представени в низходящ ред по производителност и цена. В Extreme performance влизат само твердотелни дискове (SSD). В двете други нива – дискове с магнитен принцип, които се различават по скоростта на въртене и, съответно, производителността.
Носителите на информация от един и същи ниво и размер се комбинират в RAID масив, образувайки RAID група (RAID group, накратко – RG); информация за наличните и препоръчителни нива на RAID може да прочетете в официалната документация. От RAID групите от едно или повече нива се формират пулове за съхранение на данни (Storage pool), от които след това се разпределя свободното място. От пуловете се отделя пространство за файлови системи и LUN.
Каква е целта на Tiering?
Накратко и абстрактно: за да се постигне по-добър резултат, използвайки минимални ресурси. По-конкретно, резултатът обикновено се разбира като съвкупност от характеристики на СХД – скорост и време за достъп, цена на съхранение и други. Под минимални ресурси се разбират най-малките разходи: пари, енергия и т.н. FAST VP именно реализира механизмите за преразпределение на данни по различни нива в СХД Unity/Unity XT. Ако ми вярвате, можете да пропуснете следващия абзац. За останалите ще разкажа малко по-подробно.
Правилното разпределение на данните по нива на съхранение позволява да се спести от общата цена на СХД, жертвайки скоростта на достъп до определена рядко използвана информация, и да се увеличи производителността, премествайки често използваните данни на по-бързи носители. Някой може да възрази, че и без tiering нормалният администратор знае къде да постави данните, какви желателни характеристики на СХД са нужни за неговата задача и т.н. Несъмнено, така е, но ръчното разпределение на данните има свои недостатъци:
- изисква време и внимание от администратора;
- не винаги е възможно да се "прекроят" ресурсите на СХД според променените условия;
- изчезва важното предимство: унифициран достъп до ресурси, находящи се на различни нива на съхранение.
За да намалите притеснението на администраторите на хранилищата относно сигурността на работните места, ще добавя, че правилното планиране на ресурсите е също толкова необходимо. Сега, когато задачите за подреждане са обрисувани накратко, нека видим какво можем да очакваме от FAST VP. Тук е времето да се върнем към определението. Първите две думи – Fully Automated – буквално се превеждат като „напълно автоматизирани“ и означават, че разпределението по слоеве се извършва автоматично. А Virtual Pool е пул от данни, който включва ресурси от различни слоеве на съхранение. Ето как изглежда това:
Отпускайки се напред, ще кажа, че FAST VP премества данни само вътре в един пул, а не между няколко пула.
Задачите, решавани от FAST VP
Първо, да говорим абстрактно. Имаме пул и някакъв механизъм, който може да переразпределя данните вътре в този пул. Имайки предвид, че нашата задача е постигането на максимална производителност, нека си зададем въпроса: по какви начини можем да я постигнем? Може да има няколко начина и тук FAST VP предлага на потребителя нещо повече от обикновено подреждане на хранилището. Ето как FAST VP може да увеличи производителността на пула:
- Разпределение на данните по различни типове дискове, нива
- Разпределение на данните между дисковете от един и същ тип
- Разпределение на данните при разширяване на пула
Преди да разгледаме как се решават тези задачи, трябва да знаем някои необходими факти за работата на FAST VP. FAST VP работи с блокове от определен размер – 256 мегабайта. Това е минималният непрекъснат „парче“ данни, което може да бъде преместено. В документацията той е наречен именно така: slice. От гледна точка на FAST VP всички RAID-групи се състоят от набор от такива „парчета“. Соответно, всяка статистика за вход-изход се натрупва за такива блокове данни. Защо е избран точно този размер на блока и ще бъде ли той намален? Блокът е достатъчно голям, но това е компромис между детайлността на данните (по-малък размер на блока – по-точно разпределение) и наличните изчислителни ресурси: при съществуващите строги ограничения на оперативната памет и голямото количество блокове данни статистиката може да заема твърде много и броят на изчисленията ще нарасне пропорционално.
Как FAST VP разполага данните в пула. Политики
За да управлявате разположението на данните в пула с активиран FAST VP, съществуват следните политики:
- Най-висок достъпен слой
- Авто-слой
- Започнете с висок слой, след това авто-слой (по подразбиране)
- Най-нисък достъпен слой
Те влияят както на първоначалното разположение на блока (данните се записват за първи път), така и на последващото преразпределение. Когато данните вече са разположени на дисковете, преразпределението ще бъде инициирано по график или ръчно.
Най-високият достъпен слой се опитва да разположи нов блок на най-високопроизводителния слой. При недостатък на място на него – на следващия по производителност, но след това данните могат да бъдат преместени на по-високопроизводителен слой (при наличие на място или изтласквайки други данни). Авто-слоят разполага нови данни на различни слоеве в зависимост от размера на наличното пространство, а преразпределянето им зависи от търсенето и свободното място. Започнете с висок слой, след това авто-слой – политика по подразбиране и също така препоръчителна. При първоначалното разположение работи като Най-висок достъпен слой, а след това данните се преместват в зависимост от статистиката за използване. Политиката Най-нисък достъпен слой се стреми да разположи данните на най-нископроизводителния слой.
Преместването на данни става с нисък приоритет, за да не пречи на полезната работа на СХД, но има настройка "Скорост на преместване на данни", която променя приоритета. Има особеност: не всички блокове данни имат еднаква последователност за преразпределение. Например, блоковете, маркирани като метаданни, ще бъдат преместени на по-бърз слой първо. Метаданните са, ако мога да се изразя така, "данни за данните", някаква допълнителна информация, която не е потребителски данни, но съдържа тяхното описание. Например, информацията в файловата система за това в кой блок се намира конкретен файл. Значи, скоростта на достъп до данните зависи от скоростта на достъп до метаданните. Като се има предвид, че метаданните обикновено са много по-малки по размер, се очаква печалбата от тяхното преместване на по-високопроизводителни дискове да бъде по-голяма.
Критериите, които Fast VP използва в работата си
Основният критерий за всеки блок, в груби линии, е характеристиката „търсеност“ на данните, която зависи от количеството операции по четене и запис на фрагмента от данни. Тази характеристика при нас се нарича „Температура“. Има търсени (горещи) данни, които са „по-горещи“ от нетърсените. Тя се изчислява периодично, по подразбиране с интервал от един час.
Функцията за изчисление на температурата има следните свойства:
- При липса на вход-изход данните с времето „изстиват“.
- При сравнително равномерно натоварване във времето температурата първоначално се покачва и след това се стабилизира в определен диапазон.
След това се вземат предвид политиките, описани по-горе, и свободното пространство на всеки tier. За наглядност ще покажа картинка от документацията. Тук червеният, жълтият и синият цвят обозначават блокове с висока, средна и ниска температура съответно.
Но да се върнем към задачите. Така че, можем да преминем към анализа на това, което се прави за решаване на задачите на FAST VP.
А. Разпределение на данните по различни типове дискове, нива
Собствено, това е основната задача на FAST VP. Останалите, в известен смисъл, са производни от нея. В зависимост от избраната политика, данните ще се разпределят по различни нива на съхранение. Първо се взема предвид политиката на разполагане, след това температурата на блоковете и размерът/скоростта на RAID-групите.
За политиките Най-висок/Най-нисък наличен Tier всичко е достатъчно просто. За останалите двама случая стоят по следния начин. По различните нива данните се разпределят, като се вземат предвид размерът и производителността на RAID-групите: така, че отношението на сумарната „температура“ на блоковете към „условната максимална производителност“ на всяка RAID-група да бъде приблизително еднакво. По този начин, натоварването се разпределя сравнително равномерно. По-търсените данни се преместват на бързи носители, а рядко използваните – на по-бавни. В идеалния случай разпределението трябва да изглежда приблизително така:
Б. Разпределение на данните между дисковете от един тип
Помните, в началото писах, че носителите на информация от един или няколко Какви нива комбинират в единен пул? При единствено ниво за FAST VP също има работа. За да бъде производителността на дадено ниво максимална, е желателно данните да бъдат равномерно разпределени между дисковете. Това ще позволи (в теорията) да се постигне максимален брой IOPS. Данните в RAID групата могат да се считат за равномерно разпределени между дисковете, но между RAID групите това далеч не винаги е така. При дисбаланс FAST VP ще премества данни между RAID групите пропорционално на техния обем и 'условната производителност' (в числово изражение). За нагледност ще покажа схема за ребалансиране между три RAID групи:
В. Разпределение на данните при разширяване на пул
Тази задача е частен случай на предишната и се изпълнява, когато в пула се добавя RAID група. За да не стои новодобавената RAID група без работа, част от данните ще бъде преместена на нея, а следователно и натоварването на всички RAID групи ще се переразпредели.
Изравняване на износа на SSD
С помощта на изравняване на износа FAST VP може да удължи живота на SSD, въпреки че тази функция не е пряко свързана с Storage Tiering. Тъй като информацията за температурата вече е налична, броят на записите също се взема предвид, блоковете данни можем да преместим, така че би било логично за FAST VP да реши и тази задача.
В случай, че броят на записите в една RAID група значително превишава броя на записите в друга, FAST VP ще переразпредели данните в съответствие с броя на операциите по запис. От една страна, това облекчава натоварването и запазва ресурса на едни дискове, от друга страна, увеличава 'работата' за по-малко натоварените, повишавайки общата производителност.
Таким образом, FAST VP поема традиционните задачи на Storage Tiering и прави още малко над това. Всичко това позволява да се съхраняват данни доста ефективно в СХД семейство Unity.
Няколко съвета
- Не пренебрегвайте четенето на документацията. Има добри практики и те работят доста добре. Ако им следвате, обикновено не възникват сериозни проблеми. Останалите съвети основно повтарят или допълват тях.
- Ако сте настроили и включили FAST VP, е по-добре да го оставите включен. Нека разпределя данните в предназначеното за него време, отколкото веднъж годишно и да оказва сериозно влияние върху производителността на другите задачи. В такива случаи преразпределението на данните може да отнеме много време.
- Внимателно подбирайте времето за релокация. Въпреки че изглежда очевидно, се стремете да изберете час с минимален товар върху Unity и отделете достатъчно време.
- Планирайте разширяване на СХД и правете това навреме. Това е обща препоръка, която е важна и за FAST VP. Ако обемът на свободното пространство е много малък, преместването на данни ще се забави или ще стане невъзможно. Особено, ако не сте се съобразили с точка 2.
- При разширяване на пула с включен FAST VP не трябва да започвате с най-бавните дискове. Тоест, или добавяте всичките планирани RAID групи веднага, или първо добавяте най-бързите дискове. В такъв случай преразпределението на данните на новите 'бързи' дискове ще увеличи общата скорост на пула. В противен случай, започвайки с 'бавните' дискове, може да се стигне до много неприятна ситуация. Първо ще се прехвърлят данни на новите, сравнително бавни дискове, а след това, при добавяне на по-бързи, обратно. Тук има нюанси, свързани с различните политики на FAST VP, но в общия случай такава ситуация е възможна.
Ако се запознавате с този продукт, можете да изпробвате Unity безплатно, изтегляйки виртуалния апарат Unity VSA.
В края на материала споделям няколко полезни линка:
- Страница
- – кратко описание на функцията
- , формат pdf
Заключение
Искам да напиша много, но разбирам, че не всички подробности ще бъдат интересни на читателя. Например, може да се разкаже по-подробно за критериите, по които FAST VP взема решение за прехвърляне на данни, за процесите на анализ на статистиката на входно-изходните операции. Темата за взаимодействието с , което предизвиква необходимостта от отделна статия. Може да се пофантазира и относно развитието на тази технология. Надявам се, че не е било скучно и не съм ви изморил. До нови срещи!
Източник: habr.com
