Это райтап об одном из заданий, которое мы приготовили для отборочного этапа CTFZone, прошедшего в конце ноября. О процессе подготовки к квалификации можно прочитать здесь.

Вы начинаете с двумя файлами: decrypt_flag.py и ntfs_volume.raw. Давайте взглянем на скрипт. Он открывает файл c именем key.bin, а затем при помощи цикла пробует взять из каждого смещения внутри файла бинарную строку размером 34 байта, которая затем используется в качестве входных данных для функции PBKDF2. Каждый возвращенный ключ используется в качестве XOR-ключа для расшифровывания вшитой в код зашифрованной строки. Если в расшифрованной форме ее хеш MD5 совпадает с заранее определенным значением, скрипт использует полученные данные, чтобы сформировать и напечатать флаг.

Итак, вам нужно найти файл key.bin. Просто перебрать все смещения внутри файла образа (ntfs_volume.raw) нельзя, так как процесс поиска ключа будет слишком медленным. Правилами это не запрещено, но до конца CTF вы точно не успеете.

Файл образа содержит таблицу разделов MBR с одним разделом. Его смещение — 2048 512-байтовых секторов, а содержит он файловую систему NTFS, но файла key.bin там нет:

$ fls -o 2048 -r -p ntfs_volume.raw | grep -F key.bin | wc –l 0

NTFS хранит имена файлов в кодировке UTF-16LE. Давайте попробуем поискать в ней!

Результаты поиска записей о файле

Изучив результаты поиска, сфокусируемся на файловых записях, которые начинаются с сигнатуры FILE [1]. Вот единственная такая запись:

Найденная запись

Цель уже близка! Запись о файле у нас есть, но нам нужны данные. В NTFS они хранятся в атрибуте $DATA, который может быть резидентным или нерезидентным [2]. У записи, которую мы нашли, этот атрибут начинается по смещению 0×3AADD00 и указывает на нерезидентные данные (это означает, что информация хранится вне записи о файле).

Так где же именно находятся данные нужного файла? Чтобы ответить на этот вопрос, придется декодировать так называемые mapping pairs, или data runs (пары «длина блока — смещение блока») [3]. Data runs искомого файла следующие (обратите внимание на смещение 0×3AADD40): 22 53 01 A0 4E 21 05 31 C1 11 38 30 00. Или, если мы их перегруппируем:

1.	22 53 01 A0 4E 2.	21 05 31 C1 3.	11 38 30 00

Файл состоит из трех фрагментов, размер первого из которых составляет 339 кластеров, а начинается он с кластера #20128. Для нашего кода, использующего PBKDF2, этот фрагмент крупноват. Как указано в заголовке файловой системы, размер одного кластера — 4096 байт:

$ fsstat -o 2048 ntfs_volume.raw | grep 'Cluster Size' Cluster Size: 4096

Давайте взглянем на данные вот по этому смещению (в байтах):
2048 * 512 + 20128 * 4096 = 83492864. Извлечем отсюда любое значимое количество информации (например, 128 байт), вставим в новый файл, который назовем key.bin, запустим скрипт… Ничего не получилось.

Возможно, файл хранился не в текущей, а в предыдущей версии файловой системы (предыдущее форматирование) — не забывайте, что мы не видели записи об удаленном файле с таким именем. Какой раньше был размер у кластеров? Давайте поищем заголовок файловой системы с сигнатурой NTFS [4]. Может, нам повезет и мы действительно найдем заголовок от предыдущего форматирования.

Результаты поиска заголовка файловой системы

Первая и последняя позиции в выдаче относятся к нынешней файловой системе, а вот заголовки файловой системы, которые расположены между ними, кажется, принадлежат к предыдущему форматированию. И в них другой размер кластера!

Заголовок файловой системы из предыдущей версии

Вот такой размер сектора записан по смещению 0×4554800B: 00 02, или 512. А вот такой размер кластера записан по смещению 0×0x4554800D: F7, или 247.

Итак, размер кластера (в байтах) у нас 512 * 247 = 126464. Ерунда какая-то! Если верить парсеру NTFS [5], такое значение должно обладать знаком и обрабатываться специальным образом, значит реальный размер кластера (в секторах) — это 1 << –(–9) = 512. Или, если в байтах, 512 * 512 = 262144. Теперь звучит более правдоподобно.

Данные начинаются вот по этому смещению (в байтах):
2048 * 512 + 20128 * 262144 = 5277483008. Давайте еще раз попробуем провернуть тот же трюк с хранящейся там информацией… Опять провал! Что же не так? У нас тут CTF, значит «не так» может быть все что угодно.

Таск, над которым мы бьемся, называется In the Shadows. Не исключено, что он имеет какое-то отношение к теневым копиям тома. Итак, у нас есть файл из файловой системы, которая раньше существовала в этом томе. Просто взять и смонтировать ее теневую копию мы, к сожалению, не можем, зато знаем точное смещение, на котором начинаются данные! Это 5277483008, или, внутри раздела, 5277483008 – 2048 * 512 = 5276434432.

Согласно спецификациям формата VSS [6], перенаправленные блоки данных описываются в структуре Block descriptor, содержащей 64-битное поле, в котором хранится оригинальное смещение (внутри тома), а также 64-битное поле, описывающее целевое смещение блока (внутри тома). Давайте поищем 5276434432 как 64-битное число little endian.

В выдаче — только два результата, и лишь один из них расположен по четному смещению.

Найденный дескриптор блока

Смещение целевого блока: 00 00 9B 03 00 00 00 00, или просто 60489728. Окончательное смещение: 60489728 + 2048 * 512 = 61538304. Экспортируем отсюда некоторое количество данных в новый файл с именем key.bin, и…

$ ./decrypt_flag.py ctfzone{my_c0ngr4t5_t0_u,w311_d0n3_31337}

Готово!

Ссылки

1. https://flatcap.org/linux-ntfs/ntfs/concepts/file_record.html
2. https://flatcap.org/linux-ntfs/ntfs/attributes/data.html
3. https://flatcap.org/linux-ntfs/ntfs/concepts/data_runs.html
4. https://flatcap.org/linux-ntfs/ntfs/files/boot.html
5. https://github.com/msuhanov/dfir_ntfs/blob/94bb46d6600153071b0c3c507ef37c42ad62110d/dfir_ntfs/BootSector.py#L58
6. https://github.com/libyal/libvshadow/blob/master/documentation/Volume%20Shadow%20Snapshot%20(VSS)%20format.asciidoc#431-block-descriptor

Мои последние исследования, результат которых описан в предыдущих статьях, привели меня к мысли: а что, если создать систему, противоположную Системе подавления — Систему Раскрытия Потенциала, применимую к планете Земля и человечеству? Данная система описывает правила такого устройства многомерной среды обитания существ, в которой энтропия сознания сведена к минимуму. Живущие/играющие в ней существа реализуют весь доступный им Потенциал — совокупность всех их интеллектуальных, физических и всех прочих ресурсов, данных им во всём пространстве и времени, в полном объёме. Иначе говоря, как сделать идеальную игру?

Дисклеймер

Эта статья — концепт-документ, в котором я описываю подход к разработке Системы раскрытия потенциала, а не дизайн-документ. Излишние на мой взгляд подробности и детали опущены намерено, чтобы сосредоточиться на сути Системы раскрытия потенциала. Я не гарантирую, что вы поймёте всё, о чём будет сказано в статье и что она полностью соответствует вашему мировоззрению, подходу к познанию и к привычной стилистике читаемых вами статей. Изложенные ниже идеи являются моим личным мнением, философскими размышлениями на тему и не претендуют на полную непогрешимость. Сколько людей, столько и хэшей сознания, я лишь делюсь своим в осторожном предположении, что кому-то это всё будет интересно. Возможно кто-то, погрузившись достаточно глубоко в мои мысли, сможет взглянуть на привычные вещи под новым углом или же найти источник вдохновения. Всем peace! Погнали.

Идея идеальной игры

Почти десять лет назад я писал научно-фантастический роман “Другая сторона бесконечности”, по сути просто выдавая потоком содержимое своего подсознания. Смысл написанного в полной мере дошёл до меня только сейчас и он поразил меня своей глубиной и кристальной чистотой разгадок тайн Мироздания. Например, детальным описанием регрессионной терапии, о которой тогда я на уровне сознания не знал ровно ничего, или же инверсию Системы подавления потенциала в Систему раскрытия потенциала, о чём я тогда имел весьма смутные представления. Сейчас я разрабатываю новый вариант книги, в котором описываю переход человечества в Систему раскрытия потенциала более системно, зная гораздо больше деталей устройства нашего мира и понимая, что никакая это не фантастика, а самый настоящий вариант нашего возможного будущего.

Один из моих главных жизненных интересов — создание игровых миров с необычными и увлекательными правилами взаимодействия игроков между собой и с окружением. Создание миров в той или иной форме было доступно человеку всегда, а с появлением видеоигр эта деятельность вышла на новый уровень. Люди уже создают полноценные виртуальные вселенные, в которых проводят эксперименты с правилами взаимодействия игроков между собой и с самим миром. И тенденция такова, что с каждым годом “виртуального” контента, который имеет вполне реальное влияние на сознания людей, становится всё больше, а технологии погружения совершенствуются. По факту, потенциал человечества всё больше переключается в миры, которые этим же человечеством и создаются. Всё идёт к тому, что рано или поздно будут созданы совершенно необъятные вселенные, каждая из которых даёт свой уникальный опыт.

Варясь вокруг да около этой индустрии, я понял, что ключевым универсальным правилом хорошей игры является то, что она позволяет достигать состояния потока и находиться в нём продолжительное время. Поток в рамках игры — это трансовое состояние погружения в процесс игры, достигаемый, когда решение какой-либо игровой задачи не очень легко, не невозможно, и трудно ровно в той степени, в которой игроком для её решения задействована значительная часть его потенциала, интеллектуальных и иных ресурсов. Важным аспектом такого игрового потокового состояния является то, что игровые задачи игроку интересны сами по себе и нахождение в потоке при их выполнении вызывает потерю чувства времени и лёгкую эйфорию.

Однажды, когда я рассматривал приведённый выше арт к многопользовательской ролевой игре Wildstar, в голове у меня щёлкнуло и я понял: на ней изображено, как два существа, играя, находятся в состоянии потока. И у меня возникло понимание, что мир, близкий к идеальному, это тот, в котором подобные состояния потока не являются случайными и сиюминутными, нахождение в них взято за правило, и сам мир, все его аспекты, способствуют к пребыванию в потоке всех существ, находящихся в этом мире. Получается, что основное правило хорошего “виртуального” мира выполняется в этом “реальном” мире в полной мере. Что это за мир? Какими аспектами он обладает? Возможно ли его в той или иной мере сделать или достичь? Мне удалось через маленькую щёлочку заглянуть в него, однако этого было достаточно, чтобы глубинное понимание его сути пришло. Теперь на все эти вопросы я постепенно нахожу ответы, собирая кусочки этого мира у себя в голове и которые я собираюсь переложить в свою книгу. Части многомерной мозаики устройства того мира, находящегося под покровительством Системы Раскрытия Потенциала, я постепенно нахожу в различных аспектах жизни на планете Земля — произведениях культуры и искусства, исследованиях, людях, эмоциях, чувствах, материальных и нематериальных объектах, и т.д. И тут возникает вопрос — где источник этих кусочков мозаики?

Всё, что существует на свете, когда-то было всего лишь мечтой. Всё дело в том, что тот близкий к совершенному мир постепенно материализуется в нашей с вами реальности. Человечество жаждет находиться в таком мире и тоскует по нему — вспомните, например, ажиотаж вокруг Аватара Кэмерона, в котором была показана модель такого гармоничного мира. Человек, даже одним шажком попав на Пандору, как Джейк Салли с помощью аватара или зритель с помощью магии кино, осознаёт его глубинную красоту и начинает мечтать хотя бы на какое-то время забыться в нём без остатка. А раз запрос такого количества живых существ на создание гармоничного мира есть, то значит будет и его реализация. Совершенный мир постепенно спускается к нам по этажам реальности, начиная с информационного плана, и сейчас его обретающие материализацию кусочки проявляются, например, в произведениях искусства. А я из найденных мною кусочков создаю маленькую, но полностью собранную мозаику, отображающую мозаику полную, пытаясь предугадать, каким будет этот совершенный мир и по каким правилам он будет работать, по сути собираю его хэш-сумму. А мир же, в свою очередь, является многомерной хэш-суммой из тех участков сознаний людей, которые отвечают за их представления о гармоничном мире. Общие представления о нём, в свою очередь, берутся из нашего строения как людей (материальные и нематериальные аспекты), а частные берутся из индивидуальных особенностей личности.

Где я ищу кусочки мозаики?

Путешествия между параллельными реальными и “виртуальными” мирами, попадания в иные миры и реальности через пространство и время, визиты жителей других миров на Землю, реинкарнации в иных мирах являются чуть ли не главной темой массовой культуры Японии. В огромном количестве эти приключения описываются в ранобе, манге, аниме. В качестве яркого примера, откуда я добываю кусочки мозаики и как совершенный мир материализуется в произведениях искусства, приведу аниме No Game No Life.

Сюжет таков: некий мир раздирает ужасающая война. Чтобы её остановить, “Призраки”, нейтральная группа людей в результате серии манипуляции противниками добираются до мощнейшего артефакта, позволяющего получить полный доступ к магической силе планеты и практически неограниченную силу управления пространством и материей, а также возможность перемещаться между измерениями. Однако добравшийся до артефакта лидер Призраков не может взять его в свои руки, т.к. он уже на грани жизни и смерти. Но подходящее существо, которому можно доверить артефакт, всё-таки появляется. В критический момент из-за близости источника магической сингулярности идея лидера о Совершенном Игроке (с которым он “сам с собой” постоянно играл в шахматы) материализуется, из неё появляется Тет, бог игр, берёт в руки артефакт и после этого начинает создание гармоничного мироустройства, в котором нет места ужасам прошлого. В построенном им мире распределение ключевых ресурсов и “войны” между магическими расами происходят за счёт игр, в которых расы используют свои уникальные способности. Обустраивая мир, Тет путешествует между измерениями в поиске новых игр, стратегий и талантливых игроков.

Интерпретируя сюжет в соответствии с моими представлениями, можно сказать, что лидер добирается до своего Источника, обладающего неограниченной силой и полностью осознаёт себя как чистую идею, свою изначальную версию, версию совершенного игрока. Происходит его трансформация в бога игр и после этого он в соответствии со своей Истинной Сутью, изначальной идеей, открывающей доступ к магической сингулярности, начинает обустройство своего мира, выбирая из бесконечного многообразия только то, что считает интересным и гармоничным.

Какими ещё идеями я руководствуюсь при разработке Системы раскрытия потенциала — информационной матрицы, управляющей работой близкого к совершенному мира, по которому тоскует человечество?

Суть одного из важнейших интеллектуальных артефактов мира, философии Русского Космизма можно выразить словами её основоположника, Николая Фёдорова: “Потому в природе и нет целесообразности, что её должен внести сам человек, и в этом заключается высшая целесообразность”. Также позвольте процитировать статью о Николае Фёдорове из Википедии: “Обращая внимание на факт направления эволюции к порождению разума, сознания, космисты выдвигают идею активной эволюции, то есть необходимости нового сознательного этапа развития мира, когда человечество направляет его в ту сторону, в какую диктует ему разум и нравственное чувство, берет, так сказать, штурвал эволюции в свои руки. Человек для эволюционных мыслителей — существо ещё промежуточное, находящееся в процессе роста, далеко не совершенное, но вместе сознательно-творческое, призванное преобразить не только внешний мир, но и собственную природу. Речь по существу идет о расширении прав сознательно-духовных сил, об управлении материи духом, об одухотворении мира и человека. Космическая экспансия — одна из частей этой грандиозной программы. Космисты сумели соединить заботу о большом целом — Земле, биосфере, космосе с глубочайшими запросами высшей ценности — конкретного человека”.

Могу с уверенностью заявить, что все вышеперечисленные мысли можно в полной мере отнести к моему миропониманию, которое послужило источником начала разработки Системы Раскрытия Потенциала. Для меня очевидно, что наша Вселенная дала нам бесконечно большое разнообразие всего на свете, абсолютное всё, в том числе с той целью, чтобы мы, познавая те или иные грани бесконечности, понимали, какие из них являются интересными именно для нас, и соответственно наполняли ими свои жизни. Система раскрытия потенциала в том варианте мозаики, который я собираю на основе аспектов человеческой цивилизации, старается вобрать в себя всё самое лучшее из этих граней бесконечности. Понятие “лучшего” я стараюсь брать не из своего эго, а на основе перечисленных во второй части статьи правил СРП.

Важнейшей частью разработки СРП стало осознание Системы Подавления Потенциала и деталей её работы. По сути, Система Раскрытия является во многом, если не во всём, противоположностью Системы Подавления.

Небольшая ремарка к идеям космистов. Сейчас будет самая настоящая научная фантастика и я прошу относиться к сказанному именно как к фантастике. Одна из ключевых идей Николая Фёдорова заключается в возвращении предков из небытия: на определённом этапе развития человечества все жившие когда-либо люди снова будут жить. Звучит совершенно невообразимо. Однако в настоящий момент мы, исследователи человеческого сознания, среди прочего занимаемся тем, что раскрываем людям память иных пространств и времён, в том числе и прошлого, которое они могут видеть и ощущать самостоятельно от лица живших тогда персонажей. Безо всякого анимуса и вспомогательных веществ. И мы, по сути возвращая знания прошлого и будущего, “возвращаем из небытия предков”, которые в данный момент, в этом пространстве и времени, мы и есть.

На самом деле, космос, который нам надо освоить прежде всего, бескрайний космос, доступный каждому человеку, находится у нас внутри. Осваивая именно его, мы получаем доступ к неограниченным ресурсам пространства, времени, своего Потенциала, вневременным знаниям, и что самое важное, мудрости, как всё это использовать.

Правила идеальной игры

Система Раскрытия Потенциала — информационная абстракция, описывающая такое устройство многомерной среды обитания существ, в которой энтропия сознания сведена к минимуму. Жизнь (игра) существа в СРП проходит наиболее гармонично, в соответствии с его Истинной Сутью и Аспектами естества. В Системе Раскрытия Потенциала созидательные намерения вашей Истинной Сути и ваши Аспекты не подвержены искажению, и у вас есть все необходимые ресурсы и подходящая среда, чтобы эти намерения реализовать.

Истинная Суть — источник сознания, управляющий трансцендентной сингулярностью, отвечающий за реализацию вашего Потенциала во всех временах и измерениях. Это чисто информационная сущность вне времени и пространства, которая, спускаясь по этажам реальности, в конечном счёте обретает форму игрока. Действует Истинная Суть в более плотных мирах через Сверхсознание — управляющий интерфейс, через который она управляет своими аватарами в разных временах и реальностях, и осуществляет контроль за тем опытом, который она получает с их помощью: за реализацией своего Потенциала, совокупности энергий Аспектов.

Аспекты естества напрямую связаны с энерго-информационной конструкцией человека, чакрами и их энергиями:

1. Аспект гармоничного энергообмена
2. Аспект экстатического потока, творчества и сексуальности
3. Аспект воли
4. Аспект безусловной любви
5. Аспект самовыражения
6. Аспект осознанного знания
7. Аспект космической связи

В Системе раскрытия потенциала Аспекты естества имеют равнозначное значение, без иерархии и доминации, а игрок имеет равные возможности для выражения любого Аспекта в желаемой им мере.

В Системе раскрытия потенциала потоковые состояния выражения собственного естества являются безусловной нормой. Нахождение в Потоке — стандартное состояние игрока, живущего в Системе раскрытия потенциала.

Система раскрытия потенциала избавлена от тех аспектов, которые ведут к энтропии и деградации сознания, в ней отсутствуют источники продолжительных пиковых негативных эмоций, чувств, ощущений, мыслей и действий. В ней отсутствуют те эгрегоры, которые в конечном счёте приводят к вышеперечисленному, за счёт отсутствия питательной среды для этих эгрегоров.

В Системе раскрытия потенциала закон Свободной Воли соблюдается в полном объёме: с вами могут произойти только те события, которые не идут против устремлений вашей Истинной Сути. Сама же связь ваших воплощений с Истинной Сутью кристально чистая, а любые возможные искажения ей одобрены и не идут вразрез с остальными правилами СРП.

Система раскрытия потенциала даёт играющим в ней существам только те условно негативные аспекты и ровно в том объёме, который позволяет опыту нахождения существа в Системе Раскрытия Потенциала быть захватывающим и интересным.

Система раскрытия потенциала избавлена от кармы в том виде, в котором она существует сейчас, а причинно-следственные связи контролируются и вашей Истинной Сутью, и правилами СРП.

Карма — высокоуровневый код, осуществляющий контроль над причинно-следственными связями. Как игроки могут влиять на этот код, так и код может влиять на игрока, его параметры и события, которые с ним происходят.

Любые ресурсы, вырабатываемые в Системе раскрытия потенциала, в итоге идут на пользу всем живущим в Системе существам, а паразитическое влияние внешних сознаний и систем исключено.

Живя в Системе Раскрытия Потенциала, вы являетесь кристально чистой гранью своей Истинной Сути, без любых искажений.

Система раскрытия потенциала как таковая является информационным овеществлением Аспектов всех пребывающих в ней существ. Иначе говоря, Система раскрытия потенциала — хэш всех Потенциалов всех существ, пребывающих в ней. Это также означает, что на определённом уровне осознания живущее в Системе раскрытия потенциала существо получает доступ ко всем граням этой системы.

Как общий итог, энтропия сознания существ, пребывающих в СРП, сведена к минимуму. Играющие в СРП существа могут использовать весь свой Потенциал, доступный в рамках СРП, в полном объёме.

Несмотря на всё вышеперечисленное, Система Раскрытия Потенциала является отчасти субъективной, т.к. составление её изначальной многомерной формулы, содержащей краеугольные параметры, требует серии определённых выборов и решений.

Как достичь Системы раскрытия потенциала?

Спешу обрадовать — все ресурсы, необходимые для достижения СРП у вас уже есть. Источник магической сингулярности находится внутри вас. Именно от вас зависит ваше личное будущее, степень гармонизации Аспектов вас, вашего окружения и энтропии вашего сознания. Вы сами являетесь своей личной Вселенной и вы, только вы и никто другой, вольны настроить её параметры так, как угодно вам, использовать ваш многомерный потенциал именно тем образом и в той мере, в которой желаете. Ваш главный помощник в достижении истинных целей и в полном раскрытии Потенциала — высший Аспект вас самих, Истинная Суть.

Именно это ознание (осознанное знание) является главным антидотом к вирусу Системы подавления и пропуском в Систему раскрытия потенциала — множеству миров, объединённых идеей гармонии, наполненных завораживающим опытом и удивительными приключениями.

Рады объявить, что компания «Флант» пополняет свой вклад в Open Source-инструменты для Kubernetes, выпустив альфа-версию драйвера CSI (Container Storage Interface) для Яндекс.Облака.

Но перед тем, как перейти к деталям реализации, ответим на вопрос, зачем это вообще нужно, когда у Яндекса уже есть услуга Managed Service for Kubernetes.

Введение

Зачем это?

Внутри нашей компании, ещё с самого начала эксплуатации Kubernetes в production (т.е. уже несколько лет), развивается собственный инструмент (deckhouse), который, кстати, мы тоже планируем в скором времени сделать доступным как Open Source-проект. С его помощью мы единообразно конфигурируем и настраиваем все свои кластеры, а в настоящий момент их уже более 100, причём на самых различных конфигурациях железа и во всех доступных облачных сервисах.

Кластеры, в которых используется deckhouse, имеют в себе все необходимые для работы компоненты: балансировщики, мониторинг с удобными графиками, метриками и алертами, аутентификацию пользователей через внешних провайдеров для доступа ко всем dashboard’ам и так далее. Такой «прокачанный» кластер нет смысла ставить в managed-решение, так как зачастую это либо невозможно, либо приведёт к необходимости отключать половину компонентов.

NB: Это наш опыт, и он довольно специфичен. Мы ни в коем случае не утверждаем, что всем стоит самостоятельно заниматься разворачиванием кластеров Kubernetes вместо того, чтобы пользоваться готовыми решениями. К слову, реального опыта эксплуатации Kubernetes от Яндекса у нас нет и давать какую-либо оценку этому сервису в настоящей статье мы не будем.

Что это и для кого?

Итак, мы уже рассказывали о современнем подходе к хранилищам в Kubernetes: как устроен CSI и как сообщество пришло к такому подходу.

В настоящее время многие крупные поставщики облачных услуг разработали драйверы для использования своих «облачных» дисков в качестве Persistent Volume в Kubernetes. Если же такого драйвера у поставщика нет, но при этом все необходимые функции предоставляются через API, то ничто не мешает реализовать драйвер собственными силами. Так и получилось у нас с Яндекс.Облаком.

За основу для разработки мы взяли CSI-драйвер для облака DigitalOcean и пару идей из драйвера для GCP, так как взаимодействие с API этих облаков (Google и Яндекс) имеет ряд сходств. В частности, API и у GCP, и у Yandex возвращают объект Operation для отслеживания статуса длительных операций (например, создания нового диска). Для взаимодействия с API Яндекс.Облака используется Yandex.Cloud Go SDK.

Результат проделанной работы опубликован на GitHub и может пригодиться тем, кто по какой-то причине использует собственную инсталляцию Kubernetes на виртуальных машинах Яндекс.Облака (но не готовый managed-кластер) и хотел бы использовать (заказывать) диски через CSI.

Реализация

Основные возможности

На текущий момент драйвер поддерживает следующие функции:

• Заказ дисков во всех зонах кластера согласно топологии имеющихся в кластере узлов;
• Удаление заказанных ранее дисков;
• Offline resize для дисков (Яндекс.Облако не поддерживает увеличение дисков, которые примонтированы к виртуальной машине). О том, как пришлось дорабатывать драйвер, чтобы максимально безболезненно выполнять resize, см. ниже.

В будущем планируется реализовать поддержку создания и удаления снапшотов дисков.

Главная сложность и её преодоление

Отсутствие в API Яндекс.Облака возможности увеличивать диски в реальном времени — ограничение, которое усложняет операцию resize’а для PV (Persistent Volume): ведь в таком случае необходимо, чтобы pod приложения, который использует диск, был остановлен, а это может вызвать простой приложения.

Согласно спецификации CSI, если CSI-контроллер сообщает о том, что умеет делать resize дисков только «в offline» (VolumeExpansion.OFFLINE), то процесс увеличения диска должен проходить так:

If the plugin has only VolumeExpansion.OFFLINE expansion capability and volume is currently published or available on a node then ControllerExpandVolume MUST be called ONLY after either:

• The plugin has controller PUBLISH_UNPUBLISH_VOLUME capability and ControllerUnpublishVolume has been invoked successfully.

OR ELSE

• The plugin does NOT have controller PUBLISH_UNPUBLISH_VOLUME capability, the plugin has node STAGE_UNSTAGE_VOLUME capability, and NodeUnstageVolume has been completed successfully.

OR ELSE

• The plugin does NOT have controller PUBLISH_UNPUBLISH_VOLUME capability, nor node STAGE_UNSTAGE_VOLUME capability, and NodeUnpublishVolume has completed successfully.

По сути это означает необходимость отсоединить диск от виртуальной машины перед тем, как его увеличивать.

Однако, к сожалению, реализация спецификации CSI через sidecar’ы не соответствует этим требованиям:

• В sidecar-контейнере csi-attacher, который и должен отвечать за наличие нужного промежутка между монтированиями, при offline-ресайзе попросту не реализован этот функционал. Дискуссию об этом инициировали здесь.
• Что вообще такое sidecar-контейнер в данном контексте? Сам CSI-плагин не занимается взаимодействием с Kubernetes API, а лишь реагирует на gRPC-вызовы, которые посылают ему sidecar-контейнеры. Последние разрабатываются сообществом Kubernetes.

В нашем случае (CSI-плагин) операция увеличения диска выглядит следующим образом:

1. Получаем gRPC-вызов ControllerExpandVolume;
2. Пытаемся увеличить диск в API, но получаем ошибку о невозможности выполнения операции, так как диск примонтирован;
3. Сохраняем идентификатор диска в map, содержащий диски, для которых необходимо выполнить операцию увеличения. Далее для краткости будем называть этот map как volumeResizeRequired;
4. Вручную удаляем pod, который использует диск. Kubernetes при этом перезапустит его. Чтобы диск не успел примонтироваться (ControllerPublishVolume) до завершения операции увеличения при попытке монтирования, проверяем, что данный диск всё ещё находится в volumeResizeRequired и возвращаем ошибку;
5. CSI-драйвер пытается повторно выполнить операцию resize’а. Если операция прошла успешно, то удаляем диск из volumeResizeRequired;
6. Т.к. идентификатор диска отсутствует в volumeResizeRequired, ControllerPublishVolume проходит успешно, диск монтируется, pod запускается.

Всё выглядит достаточно просто, но как всегда есть подводные камни. Увеличением дисков занимается external-resizer, который в случае ошибки при выполнении операции использует очередь с экспоненциальным увеличением времени таймаута до 1000 секунд:

func DefaultControllerRateLimiter() RateLimiter {   return NewMaxOfRateLimiter(   NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),   // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)   &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},   ) }

Это может периодически приводить к тому, что операция увеличения диска растягивается на 15+ минут и, таким образом, недоступности соответствующего pod’а.

Единственным вариантом, который достаточно легко и безболезненно позволил нам уменьшить потенциальное время простоя, стало использование своей версии external-resizer с максимальным ограничением таймаута в 5 секунд:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Мы не посчитали нужным экстренно инициировать дискуссию и патчить external-resizer, потому что offline resize дисков — атавизм, который вскоре пропадёт у всех облачных провайдеров.

Как начать пользоваться?

Драйвер поддерживается в Kubernetes версии 1.15 и выше. Для работы драйвера должны выполняться следующие требования:

• Флаг --allow-privileged установлен в значение true для API-сервера и kubelet;
• Включены --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true для API-сервера и kubelet;
• Распространение монтирования (mount propagation) должно быть включено в кластере. При использовании Docker’а демон должен быть сконфигурирован таким образом, чтобы были разрешены совместно используемые объекты монтирования (shared mounts).

Все необходимые шаги по самой установке описаны в README. Инсталляция представляет собой создание объектов в Kubernetes из манифестов.

Для работы драйвера вам понадобится следующее:

• Указать в манифесте идентификатор каталога (folder-id) Яндекс.Облака (см. документацию);
• Для взаимодействия с API Яндекс.Облака в CSI-драйвере используется сервисный аккаунт. В манифесте Secret необходимо передать авторизованные ключи от сервисного аккаунта. В документации описано, как создать сервисный аккаунт и получить ключи.

В общем — попробуйте, а мы будем рады обратной связи и новым issues, если столкнетесь с какими-то проблемами!

Дальнейшая поддержка

В качестве итога нам хотелось бы отметить, что этот CSI-драйвер мы реализовывали не от большого желания развлечься с написанием приложений на Go, а ввиду острой необходимости внутри компании. Поддерживать свою собственную реализацию нам не кажется целесообразным, поэтому, если Яндекс проявит интерес и решит продолжить поддержку драйвера, то мы с удовольствием передадим репозиторий в их распоряжение.

Кроме того, наверное, у Яндекса в managed-кластере Kubernetes есть собственная реализация CSI-драйвера, которую можно выпустить в Open Source. Такой вариант развития для нас также видится благоприятным — сообщество сможет пользоваться проверенным драйвером от поставщика услуг, а не от сторонней компании.

P.S.

Читайте также в нашем блоге:

• «Плагины томов для хранилищ в Kubernetes: от Flexvolume к CSI»;
• «Понимаем Container Storage Interface (в Kubernetes и не только)»;
• «Готовить Kubernetes-кластер просто и удобно? Анонсируем addon-operator»;
• «Расширяем и дополняем Kubernetes (обзор и видео доклада)».

Нередко от старшего поколения мы слышим магические слова о «единственной записи в трудовой книжке». И правда, приходилось встречать совершенно потрясающие истории: слесарь — слесарь высшего разряда — мастер цеха — начальник смены — главный инженер — директор завода. Это не может не впечатлять наше поколение, которое меняет работу раз, два, да что там — порой и пять, и больше. У нас есть возможность не просто менять компанию, можно менять профессию и довольно быстро в ней осваиваться. Особенно заметно это в ИТ-сфере, где встречаются весьма причудливые карьерные трансферы и кардинальные сдвиги по карьерной лестнице, как вверх, так и вниз. 

Наблюдая за этим процессом, мы поняли, что справочник профессий востребован не только школьниками, выбирающими вуз, но и взрослыми, выбирающими путь. Поэтому решили рассказать об основных специальностях, которые востребованы в ИТ-сфере. Начинаем с самой близкой нам — системный администратор. 

Всё так

Кто это?

Системный администратор — это специалист, который занимается настройкой, совершенствованием и поддержкой ИТ-инфраструктуры компании, включая оборудование, периферию, программное обеспечение и сетевые подключения. Правда, очень формальное определение?

То, чем занимается системный администратор, зависит от размера компании, сферы деятельности, опыта и навыков самого админа. Вместо того чтобы давать определение, лучше выделим конкретные типы сисадминов.

• Эникей — начинающий системный администратор, который выполняет базовые функции по настройке оборудования и программного обеспечения. Обычно помощник старшего сисадмина или админ в небольшой неайтишной компании, который закрывает текущие инциденты.
• Системный администратор (он же труъ админ) — специалист широкого профиля, который отвечает за стабильное и безотказное функционирование ИТ-инфраструктуры, осуществляет мониторинг, проводит инвентаризацию, отвечает за безопасность пользователей, занимается сетями и т.д. Это многорукий и многоголовый бог ИТ-инфраструктуры, который берёт на себя обязанности по обеспечению всей ИТ-жизнедеятельности компании. Встречается практически в любых компаниях.
• Системный архитектор-инженер — специалист, проектирующий ИТ-инфраструктуру и архитектуру сети в крупных корпорациях.
• Сетевой администратор — специалист, который занимается настройкой и развитием физических и логических сетей в компании, а также управлением системами биллинга, учёта и контроля трафика. Востребован в ЦОДах, телекоме, банках, корпорациях.
• Инженер информационной безопасности — специалист, который обеспечивает безопасность ИТ-инфраструктуры на всех уровнях. Востребован в компаниях, чувствительных к атакам и проникновению в сеть (а это и финтех, и банки, и промышленность, и проч.). 

Соответственно, решив стать системным администратором, лучше сразу спланировать, в каком направлении вы будете развиваться, потому что на должности эникея семью не прокормишь и карьеру не сделаешь.

Где нужен?

Я бы сказал, что везде, но это будет ложь. Почему-то руководители малого и среднего нейатишного бизнеса полагают, что всё можно «запихнуть» в облако, а сисадмин может быть исключительно приходящим эникеем. Поэтому нередко компании сильно страдают от хромой на все ноги ИТ-инфраструктуры (точнее, ИТ-бардака), но сисадмина не нанимают. Если вам удастся попасть в такую компанию, то в 99% случаев нужно рассматривать работу в компании как опыт и двигаться дальше, и лишь в 1% случаев удаётся переубедить босса, стать незаменимым и выстроить идеальную ИТ-среду с выверенной архитектурой и грамотным управлением (вот прямо с реального примера описываю!). 

А вот в компаниях, где ИТ является ключевой сферой деятельности (хостинги, разработчики и проч.) или же замыкает на себе операционную работу (доставки, интернет-магазины, банки, ритейл и проч.), сисадмин сразу становится востребованным специалистом, который может развиваться в одном или нескольких направлениях. Поскольку автоматизация продолжает захватывать компании, найти работу сисадмином начального и среднего уровня не составит особого труда. А когда вы станете прокачанным специалистом, компании будут за вас сражаться, потому что эникеев много, а профессионалов, как и везде, крайне мало. 

На момент написания статьи на сервисе «Хабр Карьера» 67 вакансий, связанных с системным администрированием. И вы как раз можете увидеть, что разброс «специализации» велик: от сотрудника технической поддержки до специалиста по инфобезу и DevOps. Кстати, работа в технической поддержке на старте очень быстро, качественно и глубоко прокачивает ряд навыков, ценных для системного администратора.

Средняя заработная плата

Заработную плату будем смотреть опять же на «Хабр Карьере». 

Возьмём среднюю заработную плату без выделения навыков для «Системного администратора» и для «DevOps» по данным за 2 полугодие 2019 года. Это самые популярные специальности в разделе «Администрирование», и наиболее показательные. Сравним.

Цифры, конечно, даны с учётом Москвы, в регионах ситуация поскромнее, но, что характерно, пропорции примерно такие же. И мне кажется справедливым такая разница, потому что DevOps реально более продвинутые по скиллам (если мы говорим о канонических девопсах, а не о тех, у которых одно название).

Единственное, что не хотелось бы рекомендовать, это брать джунов-девопсов после вуза. Ребята-теоретики, не познавшие ни dev, ни ops, весьма посредственно смотрятся на старте, слабо развиваются из-за непонимания того, куда двигаться и точно не стоят обозначенных денег. Всё же на узких специализациях должны быть более опытные админы, которые прошли огонь, воду, медные трубы, bash и скрипты PowerShell. 

Базовые требования к профессионалу

Требования к системному администратору отличаются от компании к компании (кому-то нужно владение 1С, 1С-Битрикс, Kubernetes, определённой СУБД и т.д.), но есть несколько базовых требований, которые, скорее всего, понадобятся в любой компании. 

• Знание и понимание сетевой модели OSI, основных протоколов.
• Администрирование операционной системы Windows и/или Unix, включая групповые политики, управление безопасностью, создание пользователей, удалённый доступ, работу с командной строкой и многое другое.
• Скриптинг bash, PowerShell, который позволяет автоматизировать и оптимизировать рутинные задачи системного администрирования. 
• Ремонт и обслуживание ПК, серверного оборудования и периферии.
• Работа с настройкой и маршрутизацией компьютерных сетей.
• Работа с почтовыми серверами и серверами телефонии.
• Установка офисных программ и приложений.
• Сетевой и инфраструктурный мониторинг. 

Это база, которую необходимо освоить на хорошем, уверенном уровне. И это не так просто, как кажется: за каждым пунктом стоит масса фишек, секретов мастерства, необходимых программных инструментов, инструкций и мануалов. По-хорошему работы с самообразованием при полной занятости на основной работе минимум на год.

Вот выучитесь и будете понимать эту шутку.

Важные личные качества

Системный администратор — специалист, который не может быть изолированным в компании и профессионально среде. Ему постоянно приходится общаться с людьми по телефону и лично, поэтому интровертные черты придётся побороть. Сисадмин должен быть:

• стрессоустойчивым — чтобы справиться с неадекватным поведением пользователей, огромным объёмом работы и общением с руководством;
• многозадачным — как правило, управление ИТ-инфраструктурой подразумевает активную работу с различными средствами, одновременное решение нескольких задач, разбор сразу нескольких инцидентов;
• умеющим управлять временем — только жёсткое планирование спасёт от факапов, сорванных работ и дедлайнов по задачам;
• коммуницирующим — умеющим слушать, анализировать и понимать, что хотят сказать пользователи (иногда это очень-очень сложно);
• технически мыслящим — увы, без умения мыслить инженерно, системно и алгоритмически в системном администрировании делать нечего.

Необходимость знания иностранных языков

Если компания предъявляет требования к знанию языков и они распространяются на специалистов, то системный администратор должен соответствовать этим правилам (например, компания предоставляет аутсорсинговые услуги для зарубежных компаний). Но вообще системный администратор должен понимать базовые команды и системные сообщения на английском языке — для большинства этого достаточно.

Однако если вы хотите расти в карьере, получать международные сертификаты, в том числе Cisco, разбираться в передовых технологиях первым, вам понадобится английский язык не ниже Upper Intermediate. Очень рекомендую сделать эту инвестицию в профессиональное развитие, это не какой-то фантастический уровень, освоить вполне реально даже без способностей к языку.

Где учиться

Профессия системного администратора интересна тем, что для входа в специальность нет специфических требований к обучению, поскольку на сисадмина как такового на особом факультете не учат. Изначально всё зависит от вас — от того, насколько вы готовы самостоятельно осваивать теорию и заниматься практикой, работать с операционными системами (Windows и Unix), периферией, безопасностью. Фактически ваш компьютер должен стать вашей учебной лабораторией (а ещё лучше, если у вас будет отдельная машина под такие задачи, чтобы процесс не мешал основной работе и учёбе).

Сказать, что системный администратор — это профессия без обучения и удел самоучек — в наше время просто преступно, потому что мы видим уровень хорошо оплачиваемых системных администраторов. А значит есть базовый «классический» набор, который вам понадобится.

• Базовое образование, желательно техническое, даст вам понимание основ алгоритмического мышления, инженерии, электроники и т.д. Оно значительно облегчит понимание специальности и ускорит её освоение. Кроме того, не стоит забывать, что для большинства российских работодателей диплом по-прежнему является важным документом при приёме на работу.
• Один или несколько сертификатов Cisco значительно прокачают ваши скиллы и сделают резюме конкурентоспособным. Например, Cisco Certified Entry Network Technician (CCENT) — первый уровень инженера-техника сетевых средств Cisco или Cisco Certified Network Associate (CCNA) Routing and Switching — один из базовых сертификатов начального уровня. С Cisco вы столкнётесь практически в любой компании, особенно крупной. В любом случае эта профессиональная сертификация — по сути золотой стандарт сетевой работы. В дальнейшем можно «получить» остальные уровни, но, по секрету скажу, уже за счёт работодателя 😉
• В зависимости от профиля работы вы можете получить соответствующие сертификаты по операционным системам, безопасности, сетям и т.д. Это реально востребованные работодателем бумаги и по своему опыту скажу — во время подготовки к экзаменам прокачиваешься в теме по полной. Если самостоятельно не заниматься, а ограничиться только занятиями курса, сдать экзамен практически невозможно.
• Есть ещё один способ образования — комплексные курсы системных администраторов Windows и Unix. Конечно, многое зависит от преподавателя и базовой организации, проводящей курс, но качество курса может разочаровать на 100%. Между тем, при удачном стечении обстоятельств такой курс здорово систематизирует знания, раскладывает их по полочкам. Если вы всё же решитесь получить такое дополнительное образование, выбирайте не вуз, а корпоративный университет, где лекцию и практику читают реальные, действующие профессионалы, а не теоретики из 90-х. 

Системный администратор — специальность, которая требует постоянного обучения новым технологиям, средствам защиты, системам управления ИТ-инфраструктуры и т.д. Без непрерывного погружения в новые материалы вы быстро потеряете свою квалификацию и стоимость на рынке.

Вам не удастся обойти азы и стать крутым профессионалом — без знания архитектуры ПК, сервера, понимания принципов работы прикладного и служебного ПО, операционных систем ничего не получится. Поэтому для системных администраторов как никогда актуален тезис «начинайте с начала».

Лучшие книги и средства обучения

1. Классика — это Эндрю Таненбаум: «Архитектура компьютера», «Компьютерные сети», «Современные операционные системы». Это три толстые книги, которые тем не менее пережили несколько изданий, отлично читаются и воспринимаются. Более того, у некоторых системных администраторов любовь к работе начинается именно с этих книг.
2. Т.Лимончелли, К. Хоган «Практика системного и сетевого администрирования» в — потрясающая «мозговправительная» книга для систематизации знаний уже готового системного администратора. Вообще у Лимончелли немало хороших книг для системных администраторов. 
3. Р. Пайк, Б. Керниган «Unix. Программное окружение», и другие книги Кернингана
4. Ноа Гифт «Python в системном администрировании UNIX и Linux» — отличная книга для фанатов автоматизации админского труда.

Кроме книг, вам пригодятся мануалы вендоров, встроенные справки операционных систем и приложений, инструкции и регламенты — как правило, в них легко найти всю нужную вам информацию. И да, нередко они на английском языке и весьма плохи в русской локализации.

Ну и, конечно, Хабр и профильные форумы — отличное подспорье для системных администраторов любого уровня. Когда мне пришлось обучаться науке Windows Server 2012, Хабр оказался сильным подспорьем — тогда мы познакомились ещё ближе.

Будущее сисадмина

Мне приходилось слышать о деградации профессии системного администратора и аргументы в пользу этого тезиса более чем слабые: справятся роботы, облака гарантируют работу без сисадмина и т.д. Вопрос о том, кто администрирует облака, например, на стороне провайдера, остаётся открытым. На самом деле, профессия системного администратора не деградирует, а трансформируется в сторону усложнения и универсальности. Поэтому если вы выбрали именно её, перед вами открываются несколько путей.

• DevOps или DevSecOps — специализация на стыке разработки, администрирования и безопасности. На данный момент внимание к DevOps только растёт и этот тренд продолжится, развиваясь в сторону контейнеризации, нагруженных приложений и систем, микросервисной архитектуры и т.д. Изучайте всё это, пока это выглядит как наиболее приоритетное будущее. 
• Информационная безопасность — ещё одно направление развития. Если раньше инфобезопасники были только в телекоме и банках, то сегодня они нужны практически в любой ИТ-компании. Сфера непростая, потребует знаний в разработке, системах взлома и защиты, — это гораздо глубже, чем установить антивирус и настроить файервол. И, кстати, для инфобеза есть отдельные специальности в вузах, поэтому если вы в начале пути, можно сразу поступать по профилю, а если «старичок», то можно рассмотреть магистратуру для углубления знаний и наличия диплома.
• CTO, CIO — руководящие должности в ИТ-сфере или ИТ-подразделениях компаний. Отличный путь для тех, кто кроме системного мышления и любви к технологиям имеет управленческие и финансовые способности. Вы будете руководить всей ИТ-инфраструктурой, проводить сложные внедрения, выстраивать архитектуры для бизнеса, и это, само собой, очень неплохо оплачивается. Однако, как показывает практика, CTO/CIO в крупной компании — это ещё и умение договариваться, объяснять, обосновывать и пробивать бюджеты, это колоссальные нервы и ответственность.
• Открыть своё дело. Например, заняться системным администрированием и поддержкой компаний как аутсорсер. Тогда вы сможете выстраивать свой график, планировать доходность и занятость, предоставлять те услуги, которые у вас выходят особенно круто. Но это непростой путь как с точки зрения набора и удержания клиентской базы, так и с точки зрения управления, финансов и права. 

Конечно, можно уйти и в телеком, и в разработку, и в менеджеры по продажам технически сложной продукции (кстати, дорогой вариант!), и в маркетинг, — всё зависит от ваших персональных склонностей и понимания специализации. А можно остаться крутым сисадмином и уделывать всех перечисленных по заработной плате и умениям. Но для этого должны сойтись ваше стремление и ваш опыт и понимание руководством вашей компании значимости ИТ-инфраструктуры (а это уже реально большая редкость). 

Мифы профессии

Как и любая профессия, системное администрирование окружено мифами. С радостью развею самые распространённые.

• Сисадмины — рабочая профессия. Нет, это интеллектуальная, сложная работа с многозадачностью и нагрузками, потому что в современном мире ИТ-инфраструктура значит слишком много в любой компании.
• Сисадмины злые. Нет, обычные — по мере характера обладателя профессии. Но их реально раздражают пользователи, которые не могут описать проблему или, чего доброго, считают себя почти что хакерами и перед тем, как позвать на помощь, усугубляют проблему донельзя.
  

  Не злые, а опасные!

• Сисадминам не нужно образование. Если вы не хотите всю жизнь «починять примусы» и заниматься базовыми вещами типа установки антивируса и других программ, учиться нужно постоянно, как самостоятельно, так и на профессиональных сертифицированных курсах. Высшее образование поможет ускорить процесс самообучения и восприятия сложной технической информации. 
• Сисадмины бездельники. О, это мой самый любимый миф! Хороший сисадмин работает с программными средствами управления ИТ-инфраструктурой и держит всю систему в порядке. Это занимает огромное количество времени, нередко требует сверхурочной работы, но внешне да, кажется, что сисадмин просто сидит за ПК, как и все мы. На взгляд обывателя это непорядок: админ же должен обернуться проводами и носиться с кримпером и стриппером наперевес. Глупость, короче. Хотя никто не безгрешен — но ленивого сисадмина вы сразу почувствуете на своей шкуре.
• Сисадмины неопрятны, ходят в растянутых свитерах и с бородой. Внешность сисадмина не продиктована никакими стандартами и зависит исключительно от его личных предпочтений.

Но вообще есть доля шутки в каждой шутке и в целом сисадмины — ребята колоритные, интересные, со своеобразной манерой общения. С ними всегда можно найти общий язык.

Главный совет

Чудес не бывает и вы не станете супер сисадмином, если будете сидеть в небольшой конторе и выполнять базовую работу. Вы непременно выгорите, разочаруетесь в профессии и будете утверждать, что это худшая работа в мире. Поэтому — развивайтесь, меняйте работу, не избегайте интересных и сложных задач — и вы сами не заметите, как станете настоящим востребованным и высокооплачиваемым профессионалом. 

P.S.: в комментариях мы как всегда ждём советы от опытных сисадминов и рассказы о том, что вам помогло в карьере, как вы пришли к этой работе, что любите в ней и что нет. Как оно, системное администрирование в 2020-м?

Данная статья написана для того, чтобы помочь выбрать для себя подходящее решение и понять отличия между такими SDS как Gluster, Ceph и Vstorage (Virtuozzo).

В тексте используются ссылки на статьи с более детальным раскрытием тех или иных проблем, поэтому описания будут максимально краткими с использованием ключевых моментов без лишней воды и вводной информации, которую вы сможете при желании самостоятельно добыть на просторах интернета.

На самом деле конечно затронутые темы требуют тоны текста, но в современном мире все больше и больше люди не любят много читать))), поэтому можно бегло прочесть и сделать выбор, а если что непонятно пройтись по ссылкам или погуглить непонятные слова))), а эта статья как прозрачная обертка для этих глубоких тем, показывающая начинку – главные ключевые моменты каждого решения.

Gluster

Начнем с Gluster, который активно используется у производителей гиперконвергентных платформ с SDS на базе open source для виртуальных сред и его можно найти на сайте RedHat в разделе storage, где предлагается выбрать из двух вариантов SDS: Gluster или Ceph.

Gluster состоит из стека трансляторов – службы которые выполняют все работы по распределению файлов и т.д. Brick – служба которая обслуживает один диск, Volume – том(пул) – который объединяет эти brick’и. Далее идет служба распределения файлов по группам за счет функции DHT(distributed hash table). Службу Sharding включать в описание не будем так как в ниже выложенных ссылках будет описание проблем связанных с ней.

При записи файл целиком ложится в brick и его копия параллельно пишется на brick на втором сервере. Далее второй файл уже будет записываться в вторую группу из двух briсk(или более) на разных серверах.

Если файлы примерно одного размера и том будет состоять только из одной группы, то все нормально, но вот при других условиях возникнут из описаний следующие проблемы:

• место в группах утилизируется неравномерно, это зависит от размеров файлов и если в группе недостаточно места для записи файла — вы получите ошибку, файл не будет записан и не будет перераспределен в другую группу;
• при записи одного файла IO идет только на одну группу, остальные простаивают;
• нельзя получить IO всего тома при записи одного файла;
• и общая концепция выглядит менее производительнее за счет отсутствия распределения данных по блокам, где проще осуществить балансировку и решить проблему равномерного распределения, а не как сейчас файл ложится в брик целиком.

Из официального описания архитектуры также невольно приходит понимание, что gluster работает как файловое хранилище поверх классического аппаратного RAID. Были попытки разработки нарезать(Sharding) файлы на блоки, но все это дополнение, которое накладывает потери производительности к уже существующему архитектурному подходу, плюс использование таких свободно распространяемых компонентов с ограничением в производительности как Fuse. Нет сервисов метаданных, что ограничивает по возможностям производительности и отказоустойчивости хранилище при распределении файлов на блоки. Более хорошие показатели производительности можно наблюдать при конфигурации “Distributed Replicated” и количество нод должно быть не менее 6 для организации надежной реплики 3 с оптимальным распределением нагрузки.

Эти выводы также связаны с описанием опыта использования Gluster и при сравнении с Ceph, а также есть описание опыта к приходу понимания этой более производительной и более надежной конфигурации “Replicated Distributed”.

В картинке показано распределение нагрузки при записи двух файлов, где копии первого файла раскладываются по трем первым серверам, которые объединены в volume 0 группу и три копии второго файла ложатся на вторую группу volume1 из трех серверов. Каждый сервер имеет один диск.

Общий вывод такой, что использовать можно Gluster, но с пониманием того, что в производительности и отказоустойчивости будут ограничения, которые создают трудности при определенных условиях гиперконвергентного решения, где ресурсы нужны еще и для вычислительных нагрузок виртуальных сред.

Есть некоторые также показатели производительности Gluster, которых можно добиться при определенных условиях ограничиваясь в отказоустойчивости.

Ceph

Теперь рассмотрим Сeph из описаний архитектуры, которые мне удалось найти. Также есть сравнение между Glusterfs и Ceph, где можно сразу понять что Ceph желательно разворачивать на отдельных серверах, так как его сервисам необходимы все ресурсы железа при нагрузках.

Архитектура Сeph более сложнее чем Gluster и есть такие сервисы как службы метаданных, но весь стек компонентов довольно непрост и не очень гибок для использования его в решении с виртуализацией. Данные укладываются по блокам, что выглядит более производительным, но есть в иерархии всех служб(компонентов), потери и latency при определенных нагрузках и аварийных условиях в пример следующая статья.

Из описания архитектуры сердцем выступает CRUSH, благодаря которому выбирается место для размещения данных. Далее идет PG — это наиболее сложная абстракция (логическая группа) для понимания. PG нужны для того, чтобы CRUSH был более эффективным. Основное предназначение PG — группировка объектов для снижения ресурс-потребления, повышения производительности и масштабируемости. Адресация объектов на прямую, по отдельности, без объединения их в PG была бы очень затратной. OSD – это сервис для каждого отдельного диска.

Кластер может иметь один или много пулов данных разного назначения и с разными настройками. Пулы делятся на плейсмент-группы. В плейсмент-группах хранятся объекты, к которым обращаются клиенты. На этом логический уровень заканчивается, и начинается физический, потому как за каждой плейсмент-группой закреплен один главный диск и несколько дисков-реплик (сколько именно зависит от фактора репликации пула). Другими словами, на логическом уровне объект хранится в конкретной плейсмент-группе, а на физическом — на дисках, которые за ней закреплены. При этом диски физически могут находиться на разных узлах или даже в разных датацентрах.

В этой схеме плейсмент-группы выглядят как необходимый уровень для гибкости всего решения, но в тоже время и как лишнее звено в этой цепочки, что невольно наводит мысли о потери производительности. Например при записи данных системе необходимо разбивать их на эти группы и потом на физическом уровне на главный диск и на диски для реплик. То есть Хеш функция работает при поиске и вставке объекта, но есть побочный эффект – это очень большие затраты и ограничения на перестройку хэша (при добавлении, удалении диска). Ещё одна проблема хэша – это чётко прибитое расположение данных, которые нельзя менять. То есть если как-то диск испытывает повышенную нагрузку, то система не имеет возможности не писать на него (выбрав другой диск), хеш функция обязывает располагать данные по правилу, независимо от того насколько диску плохо, поэтому Ceph ест много памяти при перестроении PG в случае self-healing или увеличения хранилища. Вывод, что Ceph работает хорошо(хоть и медленно), но только когда нет масштабирования, аварийных ситуаций и обновления.

Есть конечно варианты повышения производительности за счет кеширования и кеш-тиринга, но при этом необходимо хорошее железо и все равно будут потери. Но в целом Ceph выглядит заманчивее чем Gluster для продуктива. Также при использовании этих продуктов необходимо учитывать немаловажный фактор – это высокий уровень компетенций, опыта и профессионализма с большим акцентом на linux, так как очень важно все правильно развернуть, настроить и поддерживать, что накладывает еще больше ответственности и нагрузки на администратора.

Vstorage

Еще более интереснее выглядит архитектура у Virtuozzo storage(Vstorage), которую можно использовать совместно с гипервизором на тех же узлах, на том же железе, но очень важно правильно все сконфигурировать, чтобы добиться хорошей производительности. То есть развернув такой продукт с коробки на какой попало конфигурации без учета рекомендаций в соответствии с архитектурой будет очень легко, но не производительно.

Что же может сосуществовать для хранения рядом с сервисами гипервизора kvm-qemu, а это всего лишь несколько служб, где найдена компактная оптимальная иерархия компонентов: сервис клиента монтируемый через FUSE(модифицированный, не open source), служба метаданных MDS (Metadata service), служба блоков данных Chunk service, которая на физическом уровне равна одному диску и на этом все. По скорости конечно оптимально использовать отказоустойчивую схему в две реплики, но если задействовать кеширование и журналы на диски SSD, то помехоустойчивое кодирование (erase coding или raid6) можно прилично разогнать на гибридной схеме или даже лучше на all flash. С EC(erase coding) некоторый минус: при изменении одного блока данных необходимо пересчитать суммы четности. Для обхода потерь на эту операцию Сeph пишет в EC отложено и проблемы с производительностью могут произойти при определенном запросе, когда например понадобятся считать все блоки, а в случае с Virtuozzo Storage запись измененных блоков осуществляется используя подход “log-structured file system”, что минимизирует затраты на вычисления четности. Чтобы прикинуть приблизительно варианты с ускорением работы при EC и без, есть калькулятор. – цифры можно получить приблизительные зависит от коэффициента точности производителя оборудования, но результат вычислений хорошо помогает запланировать конфигурацию.

Простая схема компонентов хранения это не значит, что эти компоненты не поглощают ресурсы железа, но если подсчитать все расходы заранее, то можно рассчитывать на совместную работу рядом с гипервизором.
Есть схема сравнения потребления ресурсов железа службами Сeph и Virtuozzo storage.

Если ранее сравнивать Gluster и Ceph можно было по старым статьям, используя самые важные строки из них, то с Virtuozzo сложнее. Статей по этому продукту не так много и информацию можно черпать только с документации на английском или на русском если рассматривать Vstorage в качестве хранилища используемого в некоторых гиперконвергентных решениях в таких компаниях как Росплатформа и Акронис.

Попробую помочь с описанием этой архитектуры поэтому текста будет чуть больше, но чтобы самому разобраться в документации необходимо много времени, а имеющуюся документацию можно использовать только как справочник с помощью пересмотра оглавления или поиск по ключевому слову.

Рассмотрим процесс записи в гибридной конфигурации железа с выше описанными компонентами: запись начинает идти на тот узел с которого ее инициировал клиент(служба точки монтирования FUSE), но компонент мастер службы метаданных(MDS) конечно направит клиента на прямую к нужному чанк сервису(службе хранения блоков CS), то есть MDS не участвует в процессе записи, а просто направляет на необходимый чанк сервис. В общем можно привести аналогию записи с разливом воды по бочкам. Каждая бочка, это блок данных в 256МБ.

То есть один диск, это какое-то количество таких бочек, то есть объем диска разделить на 256МБ. Каждая копия разливается на один узел, вторая почти параллельно уже на другой узел и т.д… Если у нас три реплики и есть SSD диски, для кеша (под чтение и журналы записи), то подтверждение записи будет происходить после записи журнала в SSD, а параллельный сброс с SSD, будет продолжаться на HDD, как бы в фоновом режиме. В случае трех реплик коммит записи будет после подтверждения от SSD третьего узла. Может показаться, что сумму скорости записи трех SSD можно поделить на три и мы получим скорость записи одной реплики, но запись копий идет параллельно и скорость Latency сети обычно выше, чем у SSD, и по сути производительность записи будет зависеть от сети. В связи с этим, чтобы увидеть реальные IOPS необходимо правильно нагрузить весь Vstorage по методике, то есть тестировать реальную нагрузку, а не память и кэш, где необходимо учесть правильный размер блока данных, количество потоков и т.д.

Выше упомянутый журнал записи на SSD, работает так, что как только в него попадают данные, то сразу считываются службой и пишутся на HDD. Служб метаданных (MDS) несколько на кластер и их количество определяется кворумом, который работает по алгоритму Paxos. С точки зрения клиента точка монтирования FUSE, это папка кластерного хранилища, которая одновременно видна всем нодам кластера, каждая нода имеет смонтированного клиента по такому принципу поэтому каждому узлу доступно это хранилище.

Для производительности любого из выше описанного подхода очень важно, на этапе планирования и развертывания, правильно настроить сеть, где будет балансировка за счет агрегации и правильно подобранная пропускная способность сетевого канала. В агрегации важно правильно подобрать режим хеширования и размеры фреймов. Есть также очень сильное отличие от выше описанных SDS, это fuse с технологией fast path в Virtuozzo Storage. Который по мимо модернизированного fuse в отличие от остальных open source решений, значительно прибавляет IOPS-ов и позволяет не ограничиваться горизонтальным или вертикальным масштабированием. В общем по сравнению с выше описанными архитектурами эта выглядит более мощнее, но за такое удовольствие конечно же необходимо покупать лицензии в отличии от Сeph и Gluster.

Подводя итоги можно подчеркнуть топом из трех: первое место по производительности и надежности архитектуры занимает Virtuozzo Storage, второе Ceph и третье Gluster.

Критерии, по которому выбран Virtuozzo Storage: это оптимальный набор компонентов архитектуры, модернизированный под этот подход Fuse с fast path, гибкий набор конфигурации железа, меньшее потребление ресурсов и возможность совместного использования с compute(вычислениями/виртуализации), то есть полностью подходит для гиперконвергентного решения, в составе которого он и идет. Второе место Ceph, потому что это более производительная архитектура перед Gluster, за счет оперирования блоками, а также более гибкими сценариями и возможностью работы в более масштабных кластерах.

В планах есть желание написать сравнение между vSAN, Space Direct Storage, Vstorage и Nutanix Storage, тестирование Vstorage на оборудовании HPE, Huawei, а также сценарии интеграции Vstorage с внешними аппаратными СХД, поэтому если статья вам понравилась, то неплохо было бы получить от вас отзывы, которые могли бы усилить мотивацию на новые статьи с учетом ваших замечаний и пожеланий.