Русский
Русский
English
Статистика
Реклама

Storage

Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine

28.09.2020 06:06:32 | Автор: admin


Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.


В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.


Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.


Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Тестовый стенд


Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).


Схематично стенд выглядит следующим образом.



Стенд 1 e2k (Эльбрус)


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)


Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.


Методика тестирования


Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.


Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


Выполняться будут основные и популярные сценарии использования СХД, в частности:


первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.


Результаты тестов


Результаты тестов сведены в две таблицы.


Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


Если говорить о случайной нагрузке небольшими блоками, то:


  • с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
  • с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:


  • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:


  • оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.


О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.


Выводы и ближайшее будущее


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


Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


При случайной записи небольшими блоками оба процессора показывают равные результаты.


По показателям задержки Эльбрус выглядит значительно лучше Intel-а в потоковой нагрузке, т.е. в последовательном чтении и записи большими блоками.


Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


  • информационные системы с преобладанием операций записи;
  • файловый доступ;
  • онлайн-трансляции;
  • видеонаблюдение;
  • резервное копирование;
  • медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.


Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.


Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.


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


Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.


В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Мониторинг СХД IBM Storwize при помощи Zabbix

19.10.2020 12:14:37 | Автор: admin
В данной статье мы немного поговорим о мониторинге СХД IBM Storwize и других СХД, поддерживающих протоколы CIM/WBEM. Необходимость такого мониторинга оставлена за скобками, будем считать это аксиомой. В качестве системы мониторинга будем использовать Zabbix.

В последних версиях Zabbix компания стала уделять шаблонам гораздо больше внимания стали появляться шаблоны для мониторинга сервисов, СУБД, Servers hardware (IMM/iBMC) через IPMI. Мониторинг СХД пока остаётся вне шаблонов из коробки, поэтому для интеграции в Zabbix информации о статусе и производительности компонентов СХД нужно использовать кастомные шаблоны. Один из таких шаблонов я предлагаю вашему вниманию.


Сначала немного теории.
Для доступа к статусу и статистике СХД IBM Storwize можно использовать:
1) Протоколы CIM/WBEM;
2) RESTful API (в IBM Storwize поддерживается, начиная с ПО версии 8.1.3);
3) SNMP Traps (ограниченный набор trap'ов, нет статистики);
4) Подключение по SSH с последующим удаленным подходит для неторопливого bash-скриптинга.

Интересующиеся могут подробнее ознакомиться с различными методами мониторинга в соответствующих разделах вендорской документации, а также в документе IBM Spectrum Virtualize scripting.

Мы будем использовать протоколы CIM/WBEM, позволяющие получать параметры работы СХД без значительных изменений ПО для различных СХД. Протоколы CIM/WBEM работают в соответствии со Storage Management Initiative Specification (SMI-S). Storage Management Initiative Specification основана на открытых стандартах CIM (Common Information Model) и WBEM (Web-Based Enterprise Management), определяемых Distributed Management Task Force.

WBEM работает поверх протокола HTTP. Через WBEM можно работать не только с СХД, но и с HBA, коммутаторами и ленточными библиотеками.

Согласно SMI Architecture и Determine Infrastructure, основным компонентом реализации SMI является WBEM-сервер, обрабатывающий CIM-XML запросы от WBEM-клиентов (в нашем случае от скриптов мониторинга)
image
CIM объектно-ориентированная модель, основанная на Unified Modeling Language (UML). Управляемые элементы определяются в виде CIM-классов, у которых есть свойства и методы для представления управляемых данных и функций.

Согласно www.snia.org/pywbem, для доступа к СХД через CIM/WBEM можно использовать PyWBEM open source библиотеку, написанную на Python, и обеспечивающую разработчикам и системным администраторам реализацию протокола CIM для доступа к CIM-объектам и проведения различных операций с WBEM-сервером, работающим согласно SMI-S или другим CIM-спецификациям.
Для соединения с WBEM-сервером используем конструктор класса WBEMConnection:
conn = pywbem.WBEMConnection(server_uri, (self.login, self.password),            namespace, no_verification=True)

Это виртуальное соединение, поскольку CIM-XML/WBEM работает поверх HTTP, реальное соединение происходит в момент вызова методов для экземпляра класса WBEMConnection. В соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-8, стр. 412), в качестве CIM namespace для СХД IBM Storwize будем использовать root/ibm.

Обратите внимание, что для сбора статистики по протоколу CIM-XML/WBEM, необходимо включить пользователя в соответствующую группу безопасности. В противном случае при выполнении WBEM-запросов, вывод атрибутов экземпляра класса будет пустым.

Для доступа к статистике СХД пользователь, под которым осуществляется вызов конструктора WBEMConnection(), должен обладать правами по крайней мере RestrictedAdmin (есть для code_level > 7.8.0) или Administrator (не рекомендую по соображениям безопасности). Подключаемся к СХД через SSH и смотрим номера групп:
> lsusergrp
id name role remote
0 SecurityAdmin SecurityAdmin no
1 Administrator Administrator no
2 CopyOperator CopyOperator no
3 Service Service no
4 Monitor Monitor no
5 RestrictedAdmin RestrictedAdmin no

Добавляем пользователя zabbix в нужную группу:

> chuser -usergrp 5 zabbix

Кроме того, в соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (стр. 415) нужно включить сбор статистики на СХД. Так, для сбора статистики каждую минуту:
> startstats -interval 1

Проверяем:
> lssystem | grep statistics
statistics_status on
statistics_frequency 1


Чтобы получить все существующие классы СХД, необходимо использовать метод EnumerateClassNames().
Пример:
classnames = conn.EnumerateClassNames(namespace='root/ibm', DeepInheritance=True)for classname in classnames:     print (classname)


Для получения значений параметров СХД предназначен метод EnumerateInstances() класса WBEMConnection, возвращающий список экземпляров CIMInstance().
Пример:
instances = conn.EnumerateInstances(classname,                   namespace=nd_parameters['name_space'])for instance in instances:     for prop_name, prop_value in instance.items():          print('  %s: %r' % (prop_name, prop_value))


Для некоторых классов, содержащих большое множество экземпляров, таких как IBMTSSVC_StorageVolume, полный запрос всех экземпляров может быть довольно медленным. Он может генерировать большие объемы данных, которые должны быть подготовлены СХД, переданы по сети и обработаны скриптом. На такой случай есть метод ExecQuery(), позволяющий получить только интересующие нас свойства экземпляра класса. Этот метод предполагает использование языка запросов, подобного SQL либо CIM Query Language (DMTF:CQL), либо WBEM Query Language (WQL), для опроса CIM-объектов СХД:
request = 'SELECT Name FROM IBMTSSVC_StorageVolumeStatistics'objects_perfs_cim = wbem_connection.ExecQuery('DMTF:CQL', request)


Чтобы определить, какие классы нам нужны для получения параметров объектов СХД, читаем документацию, например How system concepts map to CIM concepts.
Так, для получения параметров (не счётчиков производительности) физических дисков (Disk Drives) будем опрашивать Class IBMTSSVC_DiskDrive, для получения параметров Volumes Class IBMTSSVC_StorageVolume, для получения параметров массивов Class IBMTSSVC_Array, для получения параметров MDisks Class IBMTSSVC_BackendVolume и т.д.

По производительности можно почитать Functional diagrams of the Common Information Model agent (конкретно Block server performance subprofile) и IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-11, стр. 415).
Для получения статистики СХД по Volumes, необходимо в качестве значения параметра ClassName указать IBMTSSVC_StorageVolumeStatistics. Необходимые для сбора статистики свойства класса IBMTSSVC_StorageVolumeStatistics можно посмотреть в Node Statistics.
Также, для анализа производительности можно использовать классы IBMTSSVC_BackendVolumeStatistics, IBMTSSVC_DiskDriveStatistics, IBMTSSVC_NodeStatistics.

Для записи данных в систему мониторинга будем использовать механизм zabbix traps, реализованный на python в модуле py-zabbix. Структуру классов СХД и их свойств расположим в словаре в формате JSON.

Загружаем шаблон на сервер Zabbix, убеждаемся что с сервера мониторинга есть доступ к СХД по протоколу WEB (TCP/5989), размещаем конфигурационные файлы, скрипты обнаружения и мониторинга на сервере мониторинга. Далее добавляем в планировщик запуск скриптов. В итоге: мы обнаруживаем объекты СХД (массивы, физические и виртуальные диски, enclosures и многое другое), передаём их в Zabbix discoveries, считываем статус их параметров, считываем статистику производительности (perfomance counters), передаём всё это в соответствующие Zabbix Items нашего шаблона.

Шаблон Zabbix, python-скрипты, структуру классов СХД и их свойств, а также примеры конфигурационных файлов, можно найти здесь: github.com/pavlovdo/pystormon.
Подробнее..

AWS reInvent. Главные анонсы первого дня (Part 2)

02.12.2020 16:10:54 | Автор: admin
Продолжаем публиковать анонсы новинок AWS с главного облачного события года AWS re:Invent. В первой части мы рассказали обо всех ключевых событиях, представленных визионером компании Andy Jassy. Прочитать можно здесь. Теперь главные изменения, анонсированные в области хранения данных.



Новый тип томов Amаzon EBS gp3


Твердотельные накопители общего назначения блочного хранилища Amazon EBS нового поколения, которые позволяют клиентам изменять производительность независимо от емкости хранилища и обеспечивают до 20% более низкую цену за GB по сравнению с существующими дисками gp2.

Новые тома gp3 обеспечивают базовую производительность 3 000 IOPS (операции ввода-вывода в секунду) и 125 MB/s (пропускная способность) при любом размере тома. Если приложению требуется более высокая производительность по сравнению с базовыми показателями, клиенты могут за дополнительную плату масштабироваться до 16 000 IOPS и 1 000 MB/s. Мигрировать данные с gp2 на gp3 можно просто при помощи существующего функционала Elastic volumes.

Тома gp3 рекомендуется использовать для приложений, где нужна высокая производительность при разумной цене, таких как MySQL, Cassandra, VDI или кластеры Hadoop.



Подробности тут

Многоуровневое ценообразование для io2 Amazon EBS в зависимости от производительности IOPS


Первые 32 000 IOPS взимаются по текущей базовой ставке. Дополнительное резервирование производительности в диапазоне 32 001-64 000 IOPS оплачивается с 30% скидкой. В результате, резервирование 64 000 IOPS за месяц теперь обходится в $3552, что на 15% экономит затраты клиентов. При использовании тома io2 Block Express производительность более 64 000 IOPS оплачивается с еще одной дополнительной 30% скидкой. Пользователи, которые на данный момент уже используют тома Amazon EBS io2 с зарезервированной производительностью более 32 000 IOPS, автоматически получат выгоду от новых цен начиная с 1 декабря 2020 г. Многоуровневое ценообразование применяется только к индивидуальным томам Amazon EBS, но не к суммарному количеству IOPS всех зарезервированных томов io2.



Подробнее тут

Поддержка multi-attach опции для томов Amazon EBS io2


Опция multi-attach позволяет использовать том Amazon EBS одновременно для записи и чтения с нескольких (до 16) серверов. Теперь эта функциональность поддерживается как для томов io1, так и io2. Виртуальные машины Amazon EC2 должны быть под управлением системы Nitro и располагаться в одной зоне доступности (Availability Zone). На данный момент поддерживается только операционная система Linux. Функциональность не требует дополнительной оплаты.



io2 Block Express (SAN в облаке)


Некоторым клиентам требуется экстремально высокая производительность в сотни тысяч IOPS. Уже сейчас в рамках предварительного запуска (Preview) вы можете протестировать диски io2, которые работают на новом поколении архитектуры блочного хранения данных EBS Block Express. Диски io2 Block Express обеспечивают пиковую производительность 256 000 IOPS и 4 000 MB/s при средних задержках менее миллисекунды. Поддерживается функциональность шифрования данных @ Rest и создание мгновенных копий (snapshots). Тома io2 Block Express подходят для задач запуска Oracle, SAP HANA, Microsoft SQL Server и SAS Analytics.



Детали тут

Инстансы Amazon EC2 R5b для оптимальной работы с io2 Block Express


Производительность доступа к Amazon EBS в новых инстансах Amazon EC2 R5b в 3x раза выше по сравнению с предыдущим поколением R5. Инстансы управляются картами AWS Nitro нового поколения. Это позволяет, в зависимости от размера виртуальной машины R5b, достигнуть производительности в диапазоне 10-60 Gbps и 43-260 IOPS. Amazon EC2 R5b подходят для высоконагруженных реляционных БД и приложений систем ERP.



Подробности тут

Подсказки по оптимизации стоимости томов Amazon EBS


Compute Optimizer анализирует настройки томов io2/io2 и gp2/gp3, а также дает рекомендации по оптимизации их производительности. Функциональность не требует дополнительной оплаты.



Оптимизация шифрования @ Rest сервиса Amazon S3


Новая возможность управления ключами шифрования SSE-KMS на уровне S3 корзины позволяет значительно улучшить внутреннюю производительность шифрования @ Rest. Отсутствие необходимости постоянных обращений к сервису управления ключами AWS KMS на 99% снижает стоимость шифрования.



Репликация данных Amazon S3 в несколько корзин


Новая функциональность позволяет одновременно реплицировать данные Amazon S3 в несколько корзин, расположенных в одном или нескольких регионах AWS. Это упрощает построение географически-распределенных решений. Основное применение снижение задержек при обращении к ресурсам Amazon S3 из разных географических локаций, а также построение распределенных катастрофоустойчивых решений.



Сильная согласованность (Strong consistency) ресурсов Amazon S3


До настоящего момента Amazon S3 обеспечивал согласованность данных чтение-после-записи (read-after-write consistency) при создании новых объектов. При модификации или удалении объектов гарантировалась согласованность в конечном счете (eventual consistency). Новая функциональность обеспечивает сильную согласованность (strong consistency) данных в корзинах Amazon S3 для всех операций. Это значительно упрощает работу с озером данных и аналитическими приложениями.



Русскоязычная Twitch-сессия


И мы продолжаем рекомендовать русскоязычный twitch-стрим AWS, который будет проходить в ключевые дни AWS re:Invent. Стримы готовят и проводят ведущие solution архитекторы AWS, которые выбрали все самое интересное и полезное из новинок и анонсов многочасовой конференции. Регистрируйтесь, подключайтесь к стримам и обсуждайте в прямом эфире.

Для тех, кто сегодня опоздал или хочет пересмотреть twitch, на котором подробно обсуждали storage, выкладываем запись
Подробнее..

Гиперконвергентная система AERODISK vAIR v2. Часть 1. Система виртуализации АИСТ

14.04.2021 06:04:04 | Автор: admin


Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.


Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:


  • Управление кластером и гипервизор АИСТ
  • Файловая система ARDFS
  • Аппаратные платформы, лицензирование и поддержка

Соответственно, в первой части мы расскажем о функциях управления vAIR v2 и более подробно о подсистеме виртуализации. Но сначала хотелось бы сказать пару слов об архитектурных изменениях в версии vAIR v2.


Коротко об архитектуре. Основные отличия между первой и второй версией


С момента выхода первой версии в 2019 году архитектура vAIR претерпела ряд изменений. Связано это в первую очередь с борьбой за стабильность, ресурсоемкость и производительность. Однако обо всем по порядку.


Описывать полностью архитектуру с нуля мы рамках этой статьи не будем. Коснёмся лишь тех отличий, которые существуют в настоящий момент между первой и второй версией. Для более глубокого знакомства с изначальной архитектурой vAIR v1 рекомендуем ознакомиться с нашими предыдущими статьями на эту тему:



На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:



Ну а теперь переходим к деталям.


Косметические изменения


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


Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.


Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.


АИСТ покинул гнездо


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


Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.


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


Данное архитектурное изменение не только позволяет импортозаместить зарубежную виртуализацию на российских предприятиях, но и открывает ряд крайне полезных сценариев использования vAIR. Разберем их:


Сценарий 1. Просто гиперконвергент


Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.



Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).


Сценарий 2. Просто виртуализация


Классическая серверная виртуализация. На локальные диски физических серверов устанавливается АИСТ, к АИСТу пригоняются сторонние СХД по файловым или блочным протоколам, и на базе этих СХД хранятся виртуальные машины.



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


Сценарий 3. Гибридный сценарий


Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.



В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.



Обзор функционала. Что нового и для чего


Функции управления


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


Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.


Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.


Для управления виртуальными машинами изнутри гостевой ОС используется на выбор два протокола: VNC (по умолчанию) или Spice. На уровне отдельных ВМ администратор может задавать разные варианты подключений.



Сам интерфейс разбит на несколько логических частей.


1) Основная область управления, в которой выполняются почти все операции



2) Основное меню, которое выдвигается наведением курсора



3) Панель действий, на которой отображаются доступные для выбранного объекта действия.



4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.



5) Ну и, наконец, информационная панель, которая показывает количество актуальных ошибок (красные) и выполняемых в данный момент действий (синие).



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



Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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


Гипервизор АИСТ


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


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



Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.


Для отдельных ВМ или для групп ВМ предусмотрены приоритеты обслуживания (QOS) из libvirt-а, где в свою очередь предусмотрены шаблоны популярных конфигураций.



Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.


Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.


Миграция виртуальных машин со сторонних гипервизоров


Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.



Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.



Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.


Мониторинг и логирование


Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.



Всё то же самое доступно и для удаленной системы мониторинга на базе Grafana.



Для логирования и алертинга предусмотрен журнал событий (ноды, порты, физические диски (SMARTCTL), сенсоры, температура и т.п.) с разбивкой по категориям и возможностью оповещения по электронной почте. Опционально поддерживается SNMP.




Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:


  • Обновление ПО без остановки и миграции виртуальных машин
  • Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
  • Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
  • Расширение кластера без остановки виртуальных машин
  • Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
  • Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:


https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf


В завершение первой части


В процессе разработки vAIR и АИСТ собственных решений в области виртуализации многие наши доверенные партнеры (которые допущены к раннему доступу), глядя на это, утверждали, что это плохая идея, потому что ВМварь и Нутаникс не догнать, они слишком крутые и великие, у них тысячи программистов по всей планете, бороды длиннее и свитера в два раза толще.


На подобные утверждения мы всегда задавали вопрос.


А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант


А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:


притча на эту тему.


Однажды странник попал в город, где шло грандиозное строительство. Мужчины ворочали большие камни под палящим солнцем. Что ты делаешь? спросил наш герой у одного из рабочих, который медленно тащил булыжник. Ты что, не видишь камни таскаю! зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: Что ты делаешь? Я зарабатываю на еду для своей семьи, получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. Что делаешь ты? Я строю храм, улыбнулся тот.

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


В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).


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


На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.


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


Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk


Всем спасибо за внимание, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Нагрузочное тестирование СХД на Эльбрусе на базе нового ядра Линукс версии 5.4

31.05.2021 06:09:55 | Автор: admin


Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.


По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.


Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.


В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:


Общие обновления:


  • переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
  • много мелких оптимизаций под скоростные твердотельные накопители;
  • и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:


  • обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
  • обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд


Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16G 1 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.



Методика тестирования


Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).


СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).


Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.


В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:


Последовательная нагрузка маленькими блоками 4k


  • 100%_read_4k_sequential
  • 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k


  • 100%_read_4k_random
  • 100%_write_4k_random

Последовательная нагрузка большими блоками 128k


  • 100%_read_128k_sequential
  • 100%_write_128k_sequential

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


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


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


100%_read_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/read-iodepth-128-numjobs-16
write_iops_log=./logs/read-iodepth-128-numjobs-16
write_lat_log=./logs/read-iodepth-128-numjobs-16
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=write
numjobs=16
runtime=2400
time_based=1


write_bw_log=./logs/4k-seq-write.results


write_iops_log=./logs/4k-seq-write.results


write_lat_log=./logs/4k-seq-write.results


[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_read_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=64
group_reporting
rw=randread
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-read.results
write_iops_log=./logs/4k-rand-read.results
write_lat_log=./logs/4k-rand-read.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_write_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=randwrite
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-write.results
write_iops_log=./logs/4k-rand-write.results
write_lat_log=./logs/4k-rand-write.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_read_128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-read.results
write_iops_log=./logs/128k-seq-read.results
write_lat_log=./logs/128k-seq-read.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=write
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-write.results
write_iops_log=./logs/128k-seq-write.results
write_lat_log=./logs/128k-seq-write.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]


Результаты тестов


Последовательная нагрузка маленькими блоками 4k


100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.


Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.


Случайная нагрузка маленькими блоками 4k


100%_read_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.


Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.


Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.


Последовательная нагрузка большими блоками 128k


100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).


При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).


А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).


Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4


Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые


Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19


Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые


Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.


В очередной раз мы убедились в отличной работе СХД на Эльбрусе среде, где преобладает последовательная нагрузка, а это аналитические СУБД, онлайн-трансляции, видеонаблюдение, обработка больших данных и т.п.


Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.


Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.


В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).


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


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

Подробнее..

Тестирование производительности и краткий обзор HPE Nimble Storage Adaptive Flash HF60

13.06.2021 08:21:39 | Автор: admin

Хочется пролить свет на интересную линейку систем хранения данных HPE Nimble Storage Adaptive Flash и попытаться раскрыть вопрос почему маркетологи решили его назвать Adaptive Flash, а не более традиционно - Hybrid Flash. Судя по поиску, существует не так много обзоров и статей, посвященных Nimble, поэтому надеюсь, что этот материал будет полезен интересующимся данной темой.

В мое распоряжение попал массив с флагманскими контроллерами - HF60. Это СХД 5-го поколения (Nimble Gen5), но уже по состоянию на 04.05.2021 компания HPE анонсировала (пока только AllFlash) 6-е поколение (Nimble Gen6), которое будет называться Allerta 6000. Adaptive Flash 6-го поколения - анонс ожидается летом 2021. Так что пока наш подопытный последнего (актуального) поколения.

Итак, чем же интересен HPE Nimble Adaptive Flash?

Давайте начнем издалека. Компания Nimble Storage берет свое начало в 2008 году и уже в 2014 наделала много шуму, объявив о революционном достижении (на тот момент) доступность систем хранения данных превысила 99,999%. В 2016 году этот показатель уже составлял 99,999928%. Традиционно, столь успешные стартапы поглощаются более крупными компаниями. Так и случилось с Nimble - в 2017 году компания влилась в ряды Hewlett Packard Enterprise. За счет чего им удалось получить такие цифры доступности (причем это не лабораторные, а реальные данные)? Если совсем коротко: архитектура и надстройка в виде аналитической платформы InfoSight. Давайте остановимся на каждом пункте чуть подробнее.

Архитектура

Если Вам лень читать, можете посмотреть видео (на англ.):

СХД Nimble в своей основе использует архитектуру CASL (Cache Accelerated Sequential Layout). В основу архитектуры заложено:

  1. Active/Standby контроллеры. Большинство других систем с двумя контроллерами Active/Active демонстрируют производительность с нулевым запасом мощности, поэтому, если один из контроллеров недоступен - вы уведёте половину скорости...

  2. Функционал редупликации/компрессии/шифрования в режиме онлайн (на лету). Подробнее как это работает ниже в описании операций чтения и записи.

  3. RAID Tripple Parity+ с фиксированным стартовым набором дисков 21шт HDD + 6шт SSD. Массив выдерживает выход из строя 3 любых дисков из одной RAID группы. Но лучшее качество Triple+ RAID не в том, что он защищает от потери любых 3 дисков. Крутая часть это +. Это позволяет системе не иметь проблем с целостностью данных, даже если на каждом отдельном диске в системе возникают ошибки параллельного чтения секторов и три диска были потеряны. Это уровень устойчивости к коррелированным по времени ошибкам, который ни один другой массив в мире даже близко не может предложить.

  4. Защита данных через каскадные многоступенчатые контрольные суммы.

  5. Память с защитой по питанию NVRAM.

  6. SSD кэш на чтение (в случае с Adaptive Flash). Важно отметить, что RAID для SSD не используется, т. к. задача кэша дать максимальную скорость. Насчет надежности можно не беспокоиться, поскольку данные в кэш копируются с защищенных RAID-ом TripleParity+ HDD (об этом ниже).

Рассмотрим алгоритмы чтения и записи

Процесс записи на массивы Adaptive FlashПроцесс записи на массивы Adaptive Flash

Распишем процесс записи:

  1. Запись от разных приложений разными блоками;

  2. NimbleOS принимает запись на NVDIMM активного контроллера;

  3. NimbleOS зеркалирует NVDIMM активного контроллера в NVDIMM Standby контроллера;

  4. NimbleOS подтверждает запись хосту;

  5. Блоки копируются в DRAM, где и происходит магия архитектуры CASL, а именно:

    a. Дедупликация с переменным блоком;

    b. Сжатие с переменным блоком;

    c. Блоки собираются в страйпы размером 10 Мбайт;

    d. Страйпы последовательно пишутся на HDD;

  6. Достойные кэша блоки или блоки из Pinned томов копируются на SSD кэш + блоки индексируются (индекс пишется на SSD и HDD в фоне). Есть 3 настройки кеширования которые можно выставить на каждый том:

    Default данные кэшируются в автоматическом режиме по выбору NimbleOS;

    Pinned настройка, которая по умолчанию копирует все данные тома на SSD диски и мы получаем All Flash на чтение;

    OFF - выключенное кеширование, т. е. SSD диски не задействованы вообще. Полезно для томов, где нет необходимости ускорять чтение;

Какие преимущества имеет такая запись?

Во-первых: количество операций Random write в бэкенде системы минимизировано. По сути, большинство операций происходит в оперативной памяти кэша контроллеров, компрессия выполняется после дедупликации, таким образом число операций ввода-вывода на дисках SSD/HDD сведено к минимуму.

Во-вторых: последовательная запись помогает избежать задержек на механических дисках. Иными словами, благодаря такой архитектуре используется максимум выгоды от обычных HDD дисков.

Процесс чтения в массивах Adaptive FlashПроцесс чтения в массивах Adaptive Flash

Рассмотрим, что происходит при чтении:

  1. Запрашиваем блок в NVDIMM. Если данные там отдаем хосту;

  2. Если блока нет, читаем из DRAM;

  3. Если блока нет, читаем с SSD:

    a. Если блок есть, проверяем контрольную сумму, разжимаем;

    b. Регидрируем и отдаем хосту;

  4. Если блока нет, читаем с HDD, блок ищем через индекс;

    a. Если блок есть, проверяем контрольную сумму, разжимаем;

    b. Регидрируем и отдаем хосту;

  5. Если блок достоин кэша, копируем на SSD;

Какие преимущества дает такой алгоритм чтения?

Во-первых: скорость ограничена не производительностью дисков, а скоростью памяти NVDIMM (которая существенно быстрее SSD дисков) т. е. контроллерами.

Во-вторых: согласно живой статистике, массив больше 95% попадает в кэш. Иными словами, имея в запасе всего 1020% SSD дисков, массив будет обеспечивать скорость All Flash больше 95% времени. Важно отметить, что это не означает что оставшиеся 5% времени данные будут читаться медленно с механических дисков. Дисков в стартовом наборе - 21 шт., при чтении их скорость суммируется. Будет иметь место то, что при чтении с HDD дисков задержка будет немного больше чем 1мс. Но не забываем, что этого легко избежать настройкой кэширования индивидуально для каждого тома.

Резюмируя по архитектуре:

  1. Данные защищены от выхода из строя 3-х любых накопителей;

  2. Данные дедуплицируются и сжимаются в памяти до записи на диски без существенного падения производительности;

  3. Данные пишутся быстро: благодаря алгоритму архитектуры CASL;

  4. Данные читаются быстро: кэшируются на SSD диски для ускорения чтения и здесь нет никакого тирринга данных как в традиционных гибридах;

  5. Данные можно дополнительно защищать шифрованием;

  6. Гибкие настройки. Можно вкл/выкл индивидуально для каждого тома: дедуп; компрессия; шифрование; кеширование; ограничение по IOPS или пропускной способности (или того и другого) и прочее;

  7. Гибкие возможности масштабирования емкости/производительности:

  • возможность масштабировать емкость (добавлять дисковые полки);

  • емкость и производительность (добавлять еще один массив в кластер, до 4 шт);

  • производительность (заменить контроллеры на более производительные).

InfoSight

Тезисы:

  • HPE InfoSight это передовая в отрасли платформа облачной аналитики InfoSight. Передовая - поскольку начала работать гораздо раньше, чем у других вендоров. А здесь важна наработка системы по времени. Чем дольше она работает, тем больше данных собирает, тем больше проблем может предотвратить. Об этом ниже.

  • Доступность СХД HPE Nimble 99,9999%, достигается благодаря применению InfoSight.

  • Миссия HPE InfoSight: сохранять маниакальный фокус на предоставлении заказчику такой поддержки, чтобы все завидовали!

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

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

По данным HPE, при использовании InfoSight 86% проблем разрешаются без участия ИТ-службы. Сюда входят инциденты как с самой СХД, так и с окружающей инфраструктурой.

InfoSight позволяет значительно сократить время на поиск проблемных узлов инфраструктуры в случае деградации производительности. Система в удобном графическом виде показывает текущее время отклика и статистику задержек за определенный период по проблемной ВМ не только относительно самой СХД, но и сети передачи данных SAN, а также приложений гипервизора. Отклонение каких-либо показателей в кратчайшие сроки позволит определить узкое место инфраструктуры. Не нужно переключаться между несколькими системами мониторинга, все показатели доступны в едином портале, так как InfoSight интегрируется с VMware VCenter. В процессе диагностики собирается только служебная информация, собственные данные заказчика не затрагиваются. Информация передается по защищенному SSL каналу.

Некоторые примеры передаваемых данных:

  • Серийный номер массива.

  • Базовая информация о работоспособности (health check).

  • Системные журналы событий.

  • Параметры настроек системы.

  • Статистика работы системы.

Самое вкусное на десерт - тестирование

Тестовая конфигурация:

  • СХД Nimble HPE Nimble Storage Adaptive Flash HF60 / 21x2TB HDD / 5.76TB (6x960GB) SSD Cache / 4x16GB FC на каждый контроллер;

  • Хост 1: Сервер HPE DL160 Gen10 / 1x Xeon 4210R / 6x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

  • Хост 2: Сервер HPE DL325 Gen10 / 1x EPYC 7551P / 8x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

  • Подключение серверов напрямую к СХД, т. к. под рукой не было коммутаторов Fibre Channel. Поэтому в серверах по 2шт двухпортовых карточки, чтоб загрузить все 4 порта на каждом контроллере СХД;

  • VMware vSphere 7;

  • Тестирование с помощью HCIbench 2.5.3;

Для начала нам было интересно сравнить наш Adaptive Flash HF60 с протестированным All Flash AF40:

Нагружаем наш массив аналогичными параметрами и в конце сводим результаты.

Первый тест: 384 потока/100%, получаем результаты:

Второй тест: 192 потока/100% чтение, получаем результаты:

Третий тест: 192 потока/100% запись, получаем результаты:

Сравниваем результаты Adaptive Flash HF60 vs All Flash AF40:

Пару слов о полученных результатах

Получаем то, что СХД с медленными 7,2k дисками дает большую производительность и меньшое время отклика чем All Flash массив. Как так? Все дело в контроллерах и архитектуре. В нашем случает стоят более производительные контроллеры и за счет магии архитектуры CASL гибриды Adaptive Flash показывают производительности сопоставимую с All Flash (контролеры используются одинаковые HF20=AF20, HF40=AF40, HF60=AF60, разница HF и AF только в конфигурации дисках). Причем скорость и задержки HF60 выигрывает при записи, где в Adaptive Flash никак не задействованы SSD.

За то время что у нас был массив мы смогли сравнить еще с одной конфигурацией All Flash XS5226D СХД QSAN. К нам попал такой результат тестирования:

Единственное, что мы не смогли повторить 464 потока при 32-х виртуалках. Поэтому сделали 448 и 480.

448/480 одновременных потоков серьезная нагрузка. Можно отметить, что здесь массив вполне играет наравне с дешевым All Flash. У QSAN очень много непонятных пиков и провалов по задержке. Поэтому Nimble существенно выигрывает по 95-му перцентилю.

Эксперименты с дудепликацией и компрессией

При 100% записи производительность проседает некритично ~ 20%. При 100% чтении почти ничего не меняется, что вполне логично. Гораздо интереснее 70/30. При наличии нулевых блоков операции чтения ускоряются при включенной компрессии.

Итого: почему его назвали Adaptive Flash а не Hybrid Flash?

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

Могу еще добавить, что наши инженеры скептически относились к данному массиву до тестирования. После первых предварительных результатов (~94k IOPS и задержки 5мс) на 100% чтение Возник спор, т. к. 94k полученных и 300k теоретических сильно отличались. Инженеры стояли на том, что невозможно получить больше на дисках 7200. После проверки конфигурации оказалось, что для тестовых машин было выключено кеширования и чтение не ускорялось вообще. После правильной настройки все взлетело. И как только они не пытались убить скорость массива не получалось (в рамках разумного естественно). В итоге лишь в условиях личного опыта у них поменялось мнение. К чему это? К тому что очень полезно брать железяку на тест, когда ее предлагают (да еще и бесплатно).

Подробнее..

Перевод Эфемерные тома с отслеживанием емкости хранилища EmptyDir на стероидах

07.09.2020 18:22:46 | Автор: admin

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

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

В Kubernetes уже есть несколько типов эфемерных томов, но их функциональность ограничена тем, что реализовано в K8s.

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

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

  • эфемерные тома общего назначения;

  • отслеживание емкости хранилища CSI.

Преимущества нового подхода:

  • хранилище может быть локальным, либо подключаемым по сети;

  • тома могут иметь заданный размер, который не может быть превышен приложением;

  • работает с любыми драйверами CSI, поддерживающими предоставление постоянных томов и (для поддержки отслеживания емкости) реализующими вызов GetCapacity;

  • тома могут иметь некоторые начальные данные, зависящие от драйвера и параметров;

  • все типовые операции с томом (создание снимка состояния, изменение размера и т.п.) поддерживаются;

  • тома можно использовать с любым контроллером приложений, принимающим спецификацию модуля или тома;

  • планировщик Kubernetes сам выбирает подходящие узлы, поэтому больше не нужно обеспечивать и настраивать расширения планировщика и изменять webhooks.

Варианты применения

Таким образом эфемерные тома общего назначения подходят для следующих вариантов применения:

Постоянная память в качестве замены оперативной памяти для memcached

Последние выпуски memcached добавили поддержку использования постоянной памяти (Intel Optane и т.п., прим. переводчика) вместо обычной оперативной памяти. При развертывании memcached через контроллер приложений можно с помощью эфемерных томов общего назначения сделать запрос на выделение тома заданного размера из PMEM с помощью CSI драйвера, например PMEM-CSI.

Локальное хранилище LVM в качестве рабочего пространства

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

Доступ только для чтения для томов с данными

Выделение тома может привести к созданию заполненного тома при:

Эти тома могут быть смонтированы в режиме только для чтения.

Как это работает

Эфемерные тома общего назначения

Ключевой особенностью эфемерных томов общего назначения является новый источник тома, EphemeralVolumeSource, содержащий все поля для создания запроса к тому (исторически это называется запрос на постоянный том, PVC). Новый контроллер в kube-controller-manager просматривает поды, создающие такой источник тома, а затем создает PVC для этих подов. Для CSI драйвера этот запрос выглядит так же, как и остальные, поэтому здесь не нужно особенной поддержки.

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

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

Для того, чтобы быть уверенным в том, что том удаляется вместе с подом, контроллер делает под владельцем запроса на том. Когда под удаляется - отрабатывает штатный механизм уборки мусора, который удаляет как запрос, так и том.

Запросам ставится в соответствие драйвер хранилища через обычный механизм класса хранилища. Хотя классы с немедленным и поздним связыванием (они же WaitForFirstConsumer) поддерживаются, для эфемерных томов имеет смысл использовать WaitForFirstConsumer, тогда планировщик может учесть как использование узла, так и доступность хранилища при выборе узла. Здесь же появляется новая функция.

Отслеживание емкости хранилища

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

Новый API CSIStorageCapacity, находящийся в стадии alpha, позволяет хранение нужных данных в etcd, так что они доступны планировщику. В отличие от поддержки эфемерных томов общего назначения при развертывании драйвера нужно включить отслеживание емкости хранилища: external-provisioner должен опубликовать информацию о емкости, получаемую от драйвера через обычный GetCapacity.

Если планировщику надо выбрать узел для пода с непривязанным томом, использующим позднее связывание, а драйвер при развертывании активировал эту функцию устанавливая флаг CSIDriver.storageCapacity, то будут автоматически отброшены узлы, у которых нету достаточно емкости хранилища. Это работает как для эфемерных общего назначения, так и постоянных томов, но не для эфемерных томов CSI, поскольку их параметры не могут быть считаны Kubernetes.

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

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

N.B. Более подробную информацию вы сможете получить, а также безопасно потренироваться на кошках стенде, а в случае совсем уж непонятной ситуации получить квалифицированную помощь техподдержки на интенсивах - Kubernetes База пройдёт 28-30 сентября, а для более продвинутых специалистов Kubernetes Мега 1416 октября.

Безопасность

CSIStorageCapacity

Объекты CSIStorageCapacity находятся в пространствах имен, при раскатке каждого драйвера CSI в своем пространстве имен рекомендуется ограничить права RBAC для CSIStorageCapacity в этом пространстве, поскольку очевидно, откуда приходят данные. В любом случае Kubernetes не проверяет это, а обычно драйверы ставятся в одном пространстве имен, так что в конечном итоге ожидается, что драйвера будут работать и не будут публиковать неверные данные (и тут мне карта поперла, прим. переводчика по мотивам бородатого анекдота)

Эфемерные тома общего назначения

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

Пример

Отдельная ветка в PMEM-CSI содержит все нужные изменения для запуска кластера Kubernetes 1.19 внутри виртуальных машин QEMU со всеми фунциями, находящимися на alpha стадии. Код драйвера не изменялся, поменялось только развертывание.

На подходящей машине (Linux, обычный пользователь может использовать Docker, смотрите тут детали) эти команды поднимут кластер и установят драйвер PMEM-CSI:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.gitcd pmem-csiexport TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intelmake start && echo && test/setup-deployment.sh

После того, как все отработает, вывод будет содержать инструкции для использования:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, runkubectl once logged in.  Alternatively, use kubectl directly with thefollowing env variable:   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.configsecret/pmem-csi-registry-secrets createdsecret/pmem-csi-node-secrets createdserviceaccount/pmem-csi-controller created...To try out the pmem-csi driver ephemeral volumes:   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Объекты CSIStorageCapacity не подразумевают чтение людьми, так что надо некая обработка. С помощью фильтров шаблона на Golang будут показаны классы хранилищ, в этом примере будут отображены имя, топология и емкость:

$ kubectl get \        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}{{end}}{{end}}' \        csistoragecapacitiescsisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Micsisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Micsisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Отдельный объект имеет такое содержимое:

$ kubectl describe csistoragecapacities/csisc-6cw8jName:         csisc-sqdntNamespace:    defaultLabels:       <none>Annotations:  <none>API Version:  storage.k8s.io/v1alpha1Capacity:     30716MiKind:         CSIStorageCapacityMetadata:  Creation Timestamp:  2020-08-11T15:41:03Z  Generate Name:       csisc-  Managed Fields:    ...  Owner References:    API Version:     apps/v1    Controller:      true    Kind:            StatefulSet    Name:            pmem-csi-controller    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1  Resource Version:  2994  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13Node Topology:  Match Labels:    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1Storage Class Name:           pmem-csi-sc-late-bindingEvents:                       <none>

Давайте попробуем создать демонстрационное приложение с одним эфемерным томом общего назначения. Содержимое файла pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates# how to use generic ephemeral inline volumes# with a PMEM-CSI storage class.kind: PodapiVersion: v1metadata:  name: my-csi-app-inline-volumespec:  containers:    - name: my-frontend      image: intel/pmem-csi-driver-test:v0.7.14      command: [ "sleep", "100000" ]      volumeMounts:      - mountPath: "/data"        name: my-csi-volume  volumes:  - name: my-csi-volume    ephemeral:      volumeClaimTemplate:        spec:          accessModes:          - ReadWriteOnce          resources:            requests:              storage: 4Gi          storageClassName: pmem-csi-sc-late-binding

После создания, как показано в инструкции выше, у нас появился дополнительный под и PVC:

$ kubectl get pods/my-csi-app-inline-volume -o wideNAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATESmy-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volumeNAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGEmy-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

Владелец PVC - под:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volumeapiVersion: v1kind: PersistentVolumeClaimmetadata:  annotations:    pv.kubernetes.io/bind-completed: "yes"    pv.kubernetes.io/bound-by-controller: "yes"    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1  creationTimestamp: "2020-08-11T15:44:57Z"  finalizers:  - kubernetes.io/pvc-protection  managedFields:    ...  name: my-csi-app-inline-volume-my-csi-volume  namespace: default  ownerReferences:  - apiVersion: v1    blockOwnerDeletion: true    controller: true    kind: Pod    name: my-csi-app-inline-volume    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f...

Ожидаемо обновилась информация для pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Micsisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Micsisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Если другому приложению надо будет больше, чем 26620Mi, планировщик не будет брать в расчет pmem-csi-pmem-govm-worker1 при любом раскладе.

Что дальше?

Обе функции все еще в разработке. Было открыто несколько заявок при alpha-тестировании. По ссылкам с предложениями по улучшениям ведется документирование работы, которую надо сделать, чтобы перейти в стадию beta, а также какие альтернативы были уже рассмотрены и отклонены:

Подробнее..

Перевод Как меняется бизнес Docker для обслуживания миллионов разработчиков, часть 1 Хранилище

24.09.2020 16:22:36 | Автор: admin


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


Цель компании Docker дать возможность разработчикам по всему миру воплотить их идеи в реальности, упрощая процесс разработки приложений. На сегодня Docker пользуются более 6.5 миллионов зарегистрированных разработчиков, мы хотим расширить наш бизнес до десятков миллионов разработчиков, которые только сейчас узнали о Docker. Краеугольным камнем нашей миссии является предложение бесплатных инструментов и сервисов, финансируемых за счет наших платных услуг по подписке.


Подробный анализ образов Docker Hub


Доставка приложений переносимым, безопасным и ресурсоэффективным способом требует инструменты и сервисы для безопасного хранения и совместного использования для вашей команды разработчиков. На сегодняшний день Docker с гордостью предлагает крупнейший в мире registry для образов контейнеров, Docker Hub, используемый более 6.5 миллионов разработчиков по всему миру. В настоящее время в Docker Hub хранится более 15ПБ образов контейнеров, охватывающих всё, начиная от популярнейших баз данных с хранением данных в оперативной памяти, и заканчивая платформами поточной передачи событий, тщательно отобранных и доверенных официальных образов Docker, а также порядка 150 миллионов образов, созданных сообществом Docker.


Согласно отчету, полученному нашими внутренними аналитическими инструментами, из 15 ПБ образов, хранящихся в Docker Hub, более 10ПБ не использовалось более полугода. Мы обнаружили, копнув глубже, что более 4.5ПБ этих неактивных образов связаны с бесплатными учетными записями. Многие такие образы использовались короткое время, включая образы, полученные из конвейеров CI с Docker Hub, настроенных так, что удаление временных образов игнорировалось.


Из-за большого объема неактивных данных, простаивающих в Docker Hub, команда столкнулась со сложным вопросом: как ограничить эти данные, за которые Docker ежемесячно платит, не влияя при этом на остальных клиентов Docker?


Основные принципы, принятые для решения проблемы были такими:


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

Помощь разработчикам в управлении неактивными образами


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


В соответствии с новой политикой, с 1 ноября 2020 года, образы, размещенные в бесплатных репозиториях Docker Hub, манифест которых не обновлялся последние полгода, будут удалены. Данная политика не применима к образам, хранимых на платных учетных записях Docker Hub, или учетных записях проверенных издателей образов Docker, а также официальным образам Docker.


  • Пример 1: Молли, пользователь бесплатной учетной записи, закачала в Docker Hub 1 января 2019 года образ с меткой molly/hello-world:v1. Этот образ никогда не скачивался с момента публикации. Этот помеченный образ будет считаться неактивным начиная с 1 ноября 2020 года, когда новая политика начнет действовать. Образ и любая метка, указывающая на него, будут удалены 1 ноября 2020 года.
  • Пример 2: У Молли есть образ без метки molly/myapp@sha256:c0ffee, закачан 1 августа 2018 года. Последнее скачивание было 1 августа 2020 года. Этот образ считается активным, и не будет удален 1 ноября 2020 года.

Минимизация влияния на сообщество разработчиков


Для бесплатных учетных записей Docker предлагает бесплатное хранение неактивных образов в течение полугода. Для тех, кому надо хранить неактивные образы, Docker предлагает неограниченное хранение образов в качестве особенности планов Pro или Team.


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



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


Для получения дополнительной информации о последних изменениях условий обслуживания обратитесь к FAQ.


Следите за сообщениями по e-mail касательно любых образов с истекающим сроком действия, либо перейдите на тарифные планы Pro или Team для хранения неактивных образов без ограничений.


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


P.S. Учитывая то, что технология Docker не теряет актуальности, как заверяют её создатели, совсем не лишним было бы изучить эту технологию от и до. Тем более это всегда в пользу, когда вы выработаете с Kubernetes. Если хотите познакомиться с best practice кейсами, чтобы понять, где и как лучше использовать Docker, рекомендую комплексный видеокурс по Docker, в котором мы разберем все его инструменты. Полная программа курса на странице курса.

Подробнее..

Перевод Доступна бесплатная версия cloud-native хранилища для Kubernetes от robin.io

21.10.2020 14:12:03 | Автор: admin


Jacky Parker Photography / Getty Images


Компания Robin, автор одноименного cloud-native решения для управления данными и приложениями корпоративных клиентов, например USAA, Sabre, SAP, Palo Alto Networks и Rakuten Mobile, сегодня рассказала о запуске новой бесплатной версии своего сервиса, в дополнение к крупному обновлению основного инструментария.


Robin.io обещает возможность cloud-native управления данными для контейнеризированных приложений с поддержкой типовых операций, например, резервное копирование и восстановление, снимки, возможность откатов и многое другое. Компания обеспечивает работоспособность на уровне железа, а также поддерживает основных поставщиков облачных услуг. Сервис не зависит от используемой базы данных, поддерживает PostgreSQL, MySQL, MongoDB, Redis, MariaDB, Cassandra, Elasticsearch и прочие.



Robin Cloud Native Storage работает с любыми нагрузками на любых платформах, основанных на Kubernetes, а также в любом облаке. Наша платформа с возможностями хранения, создания снимков, клонирования, миграции и обеспечения безопасности данных все они работают с простейшими командами предлагает командам разработчиков и DevOps-командам суперпростой, но высокопроизводительный инструмент для быстрого развертывания и управления вашими корпоративными нагрузками в Kubernetes.
Основатель и генеральный директор Robin, Partha Seetala.

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


Если говорить о корпоративных планах, то компания сегодня заявила, что она смещает фокус на цены, формируемые по потреблению, начиная с 0.42$ за узло-час (также предлагаются и годовые подписки). Корпоративный план включает поддержку 24x7 и не ограничивает число узлов и емкость хранилища.


Среди новых функций основного сервиса хранения Robin поддержка управления данными для Helm Charts, возможность указания точного местоположения данных (в основном это нужно для того, чтобы они находились как можно ближе к вычислительным ресурсам) и политики связывания, подразумевающей доступность для stateful приложений, зависящих от распределенных баз данных и платформ данных.

Подробнее..

Хранение данных. Или что такое NAS, SAN и прочие умные сокращения простыми словами

02.09.2020 14:13:27 | Автор: admin

TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.



Зачем это все?


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


Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей весьма интересная и сложная инженерная задача.


Хранение данных


Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.


По способу подключения есть следующие варианты:


  • Внутреннее. Сюда относятся классическое подключение дисков в компьютерах, накопители данных устанавливаются непосредственно в том же корпусе, где и будут использоваться. Типовые шины для подключения SATA, SAS, из устаревших IDE, SCSI.


подключение дисков в сервере


  • Внешнее. Подразумевается подключение накопителей с использованием некоторой внешней шины, например FC, SAS, IB, либо с использованием высокоскоростных сетевых карт.


дисковая полка, подключаемая по FC


По типу используемых накопителей возможно выделить:


  • Дисковые. Предельно простой и вероятно наиболее распространенный вариант до сих пор, в качестве накопителей используются жесткие диски
  • Ленточные. В качестве накопителей используются запоминающие устройства с носителем на магнитной ленте. Наиболее частое применение организация резервного копирования.
  • Flash. В качестве накопителей применяются твердотельные диски, они же SSD. Наиболее перспективный и быстрый способ организации хранилищ, по емкости SSD уже фактически сравнялись с жесткими дисками (местами и более емкие). Однако по стоимости хранения они все еще дороже.
  • Гибридные. Совмещающие в одной системе как жесткие диски, так и SSD. Являются промежуточным вариантом, совмещающим достоинства и недостатки дисковых и flash хранилищ.

Если рассматривать форму хранения данных, то явно выделяются следующие:


  • Файлы (именованные области данных). Наиболее популярный тип хранения данных структура подразумевает хранение данных, одинаковое для пользователя и для накопителя.
  • Блоки. Одинаковые по размеру области, при этом структура данных задается пользователем. Характерной особенностью является оптимизация скорости доступа за счет отсутствия слоя преобразования блоки-файлы, присутствующего в предыдущем способе.
  • Объекты. Данные хранятся в плоской файловой структуре в виде объектов с метаданными.


По реализации достаточно сложно провести четкие границы, однако можно отметить:


  • аппаратные, например RAID и HBA контроллеры, специализированные СХД.


RAID контроллер от компании Fujitsu


  • Программные. Например реализации RAID, включая файловые системы (например, BtrFS), специализированные сетевые файловые системы (NFS) и протоколы (iSCSI), а также SDS


пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure


Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.


DAS


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



Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.


SAN


Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.



Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах маршрутизаторы) и кабели, как средства построения сети. HBA специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет видеть диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.


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


NAS


Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.



Unified storage


Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.


SDS


Software-defined storage программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.


Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).



N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.


Пример SDS на основе GlusterFS


Из преимуществ SDS можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.


Гиперконвергентные системы


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



Облака и эфемерные хранилища


Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.



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


Заключение


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

Подробнее..

How to Make Your Windows 10 Laptop Work Better

17.03.2021 00:15:17 | Автор: admin
Read this article to find out how to get your laptop ready for all kinds of tasks without paying extra. And how to configure Windows 10 in the best way. We will explore how to maintain Windows 10, configure system security and laptop power settings, what software to install and how to connect peripherals. Here is the best all-round guide for you!

image



Introduction


In this guide, we will tell you about twelve easy methods to improve overall performance of your Windows 10 laptops, including steps for clearing junk files, optimizing the operating system and battery charge consumption, configuring security settings and installing additional apps.

How to free up disk space with the help of Storage settings in Windows 10


In Windows 10, there is a section entitled Storage that manages the local hard disk of your laptop and contains various storage settings. Use it for an easy way to remove unnecessary files from the system disk as well as other internal and external storage devices. Using the functionality of this section, you can quickly get rid of outdated setup and temporary files in order to free disk space fro more important data and improve disk efficiency.

In Windows 10, all main settings for the operating system, installed applications and services are concentrated into the unified and multifunctional application, Settings. There are several ways to access it.

Right-click on the Start button or press the keyboard shortcut Windows + X to open the context menu and select Settings.

image
image

Remove temporary files manually


To delete temporary files from your Windows 10 laptop, just do the following.

Open the Settings app in any way you prefer.

In the main page, click on the System tab.

image

In the left side of the Windows 10 settings panel, select Storage.

Now look to the right, find the section Storage sense and click on the link Free up space now (for Windows 10 with the official October 2018 Update or an earlier version).
image

For Windows 10 version 1903look to the right to find the section Windows 10 (C:) and click on Temporary files.

image

In the new page, the operating system will scan the available disk space, find and identify temporary files, arrange them by their properties and prepare them for being removed.

image

When the operations are accomplished, you will see the entire list of all discovered items. Check the files suggested for removal with the help of the description that includes the following lines:

  • Windows upgrade log files.
  • Thumbnails.
  • Temporary files.
  • Delivery optimization files.
  • Windows error reports generated by the operating system. Recycle Bin.
  • Temporary Internet files.
  • Windows Defender Antivirus.
  • DirectX shader cache.


Hint: Elements available for removal may differ depending on the version of the operating system and applications installed on a specific computer. Also, you may have noticed that we do not mention the Downloads folder. If you plan to select it, make sure it doesnt contain any mission-critical files before clearing its contents.

Select items for removal by checking the corresponding boxes and click Remove files.

image

The operating system will clear the selected elements immediately and free up disk space for storing more important user data.

Remove temporary files automatically


To configure automatic cleaning disk space from files you dont need any longer, do the following in the Storage section.

Open the Settings app in any way you like.

In the main page, click on the System tab again.

image

Select Storage on the left.

In the right panel, find the section Storage sense and drag the slider into On position to enable automatic disk space cleaning for the hard disk in your laptop.

image

After that, click Change how we free up space automatically below, or jump to the page where cleaning settings can be changed (just as before, we are describing the sequence of actions for Windows 10 with the October 2018 update or an earlier version).

image

For version 1903, go to the same Storage section and drag the slider for storage sense to the On position, and then use the link Configure Storage Sense or run it now to access a similar settings page.

image

In the section Storage Sense, use the dropdown menu Run Storage Sense and select one of the predefined time intervals for automatic start:

  • Every day.
  • Every week.
  • Every month.
  • During low free disk space.


image

In the next section Temporary files check the box for Delete temporary files that my apps arent using.

image

After that, set the time range for removal of deleted files from the Recycle Bin of your operating system. Use the dropdown menu Delete files in my recycle bin if they have been there for over and select the time interval, after which the bin is going to be emptied automatically.

image

After that, set the time interval in the dropdown menu Delete files in my Downloads folder if they have been there for over, to decide how long files downloaded from the Internet should be stored before they are removed automatically.

image

Advice: If you want to remove as may files as possible, choose the option 1 day. Bear in mind, though, that the Downloads folder may contain personal or important files, so it is recommended to back up all the files you need for the future before you proceed with automatic cleaning.

Now, find the section Locally available cloud content, open the dropdown menu Content will become online-only if not opened for more than and select the maximal number of days after which the files that have not been used for a long time will be removed from the hard disk of your laptop on condition, though, that their synchronized backup copy is saved to the cloud storage, OneDrive.

image

In the section Free up space now, check the box for Delete previous versions of Windows (if such line is displayed). With this option available, you may gain from 10 to 20 GB of additional free space.

Summing up, in the section Free up space now click on the button Clean now to start the process of removing the files according to the settings you have chosen in this page.

image

When all these actions are performed, some extra free space will appear in the hard disk of your laptop, or (depending on the settings) the automatic cleaning will run to optimize the storage device.

How to remove unnecessary apps in Windows 10


In order to remove unnecessary applications and games from Windows 10, here are the steps to take:

Open the Settings app in any way we have shown before.

In the main page, select the tab Apps.

image

In the left panel, look for Apps & features.

Click on it, and on the right, you will see all integrated and user-installed apps currently available for this computer. Scroll down or drag the slider down to navigate the list and find the application youd like to remove in order to gain more free space.

Advice: Click on the arrow Sort by to display the dropdown menu and choose the option Size, to see the applications that take up most space on the storage of your device.

image

Left-click on the selected application and then choose Uninstall.

The operating system will ask you to confirm your choice. Click the Uninstall button again in the system notification This app and its related info will be uninstalled.

image

The selected application will be removed and the disk space required for its installation and system files will be cleaned. Repeat the steps for other applications and games until the hard disk of your laptop is free from the programs you dont need any longer.

How to update your Windows 10 to the latest version available


Keeping Windows 10 up to date lets users access the latest system features and improvements introduced and tested by Microsoft. Besides, updating Windows 10regularly is the best way to make sure that your computer has the latest security updates capable of defending your files and programs from all kinds of network threats.

Update Windows 10 to the latest version with Windows Update service


In order to update Windows 10 to the latest version with Windows Update service, follow these steps.

Open the Settings app in any way you prefer.

Scroll down to reach the bottom of the list and select Update & Security.

image

In the left-side panel, click on Windows Update.

If the operating system doesnt show you an invitation to update it to the latest version automatically, click on the button Check for updates to find out if your machine is ready for the official update package.

image

When the check is complete, click on the link Download and install now, that you can find in the section Feature update to Windows 10. (The package containing new features and security improvements will only be available if your computing device is fully compatible with the suggested updates).

image

Then hit the button Restart now, to have the operating system prepare your laptop for installing system packages of the latest Windows 10 version.

Update Windows 10 to the latest version with Update Assistant


If your laptop doesnt shown any suggestions to update its operating system to the latest version, but you are confident that your device is absolutely compatible with it and ready for installation, you can have it done with Update Assistant.

In order to install the new version of Windows 10 with the help of Update Assistant, just do the following.

Open any web browser and visit the Microsoft official website offering support for all of their products.

In the section Windows Update now available click on Update now.

image

When the download is over, double-click on the executable file Windows10Upgrade to start the system update tool. When the User Account Control system asks you Allow this application to make changes to your device? click Yes, and the Update Assistant will start.

In the Update Assistant window, click Update now.

image

When the computer is checked for compatibility and installation of updates is possible, click Next.

image

The Update Assistant will start downloading the latest Windows 10 updates and get them ready.

image

When the process is over, click on Restart now.

image

When you complete all these steps, the Update Assistant for Windows 10 will update your laptop to the latest version while saving user files, and leaving applications and most settings unchanged.

image

Click Exit when everything is done, and you will see your laptop now having the latest version of the operating system.

How to shorten the list of apps that start with Windows 10


Many applications that people install on their laptops may change permissions and include themselves into the startup list so they can boot together with the operating system. Sometimes, they even configure additional background services to run at startup as well. Despite the fact that having third-party apps start with the operating system is sometimes an advantage, several such processes starting at the same time may have a serious impact on how quickly the laptop boots, reduce the time it can work on battery and affect overall system performance.

That is why if your Windows 10 starts with a bunch of other apps which you dont need right when your computer is ready for work, you can disable them, and here is how.

Open the Settings app using one of the methods we showed before.

In the main page, select the tab Apps.

image

In the left panel, jump to Startup.

When you look to the right, you will see the panel where you can decide which apps should start with the operating system. In the lines of corresponding applications which can affect system performance at startup, set the slider to the Off position, and the next time you boot your computer, these apps wont start in the background.

image

Advice: Open the dropdown menu Sort by with clicking on the downward arrow, and select the option Startup impact to arrange applications in a descending order by how they affect system performance when booting with Windows. Despite their attempts to reduce the number of such applications to a minimum, most users tend to never disable startup for Microsoft services like OneDrive and Windows Security Notification.

image

When certain applications are removed from the startup list, the operating system of your laptop should boot much faster.

How to back up the system drive of your Windows 10 laptop


Complete data backup for all information stored on your laptop is probably one of the best ways to secure user data against unexpected loss due to hardware failures, system errors, software compatibility issues, malware activities or theft attempts.

With all those advanced third-party tools for data backup, there is nothing to prevent you from using the good old utility to create a system image directly inside your Windows 10.

Important information: At the moment, users can still use system tools to create a system image. but it may be disabled in the future. With further official updates for Windows 10, Microsoft may decide to remove them from the list of integrated services.

As the tool for creating a system image was introduced back in earlier versions of Windows, it can be accessed directly from the Control Panel application. Initially, this app contains all main settings of the operating system, but beginning with Windows 8.1 developers started moving them to the new application, Settings, in order to display settings within a more advanced platform. Meanwhile, Control Panel only duplicates functions of the new app and contains specific tools, including Backup and Restore.

To create a complete backup of the data you store on your laptop, there is a sequence of steps to take.

Open the Control Panel app in any way you know. For example, click on the Start button which you can find in the lower left corner of the Taskbar to open the main Windows menu. Scroll down the list of available apps and services, find the section Windows System and left-click on it. Open the nested menu and select Control Panel from the list of suggested apps.

image

In the window All Control Panel Items find and select Backup and Restore (Windows 7).

image

In this page, hit the link Create a system image in the left-side panel.

image

In the new window, look under the heading Where do you want to save the backup?and check the option for On a hard disk to indicate where your backup will be stored.

With the nested menu, select the local disk where youd like to save your backup. Try to have that location on a physical disk different from the one you are backing things up from, because if the entire physical disk fails, you risk to lose all your backups. After that, click Next to continue.

image

By default, when you create a system image, the backup only includes the disks required to start your Windows 10. You can add any disks to be included into the backup by checking their boxes in the corresponding window.

In the section Confirm your backup settings check the settings you selected to create the system image, including location of the future backup and the disks selected for this process, and then hit Start backup set things going.

image

When it is over, the tool will create a full backup of your device including all data on the main hard disk and other disks which you may have selected for backup.

Also, the operating system will suggest creating a system repair disk for use in cases when the computer is unable to boot correctly. However, you can skip this part and use a bootable flash drive to access system restore options, if necessary.

How to protect files with OneDrive in Windows 10


OneDrive offers protection from ransomware, and stores selected files as permitted by the user to reduce the use of local storage to a minimum. It also features integrated functions that let you exchange various data, synchronize users settings in Windows 10, offers protection for BitLockerrecovery keys and many other useful options.

All data saved to the remote cloud service OneDrive will be available to you from anywhere in the world, including from another computer working under Windows 10 and macOS, as well as from mobile devices based on Android and iOS.

Back up contents of the folders Desktop, Documents and Pictures
In addition to its main functions, OneDrive cloud storage service also lets you backup files stored in such folders as Desktop, Documents and Pictures, without having to move their contents to the OneDrive folder.

To back up selected folders in Windows 10 to OneDrive storage, heres what you do.

On the Taskbar, look at the lower right corner and click on the cloud-shaped icon of Microsoft OneDrive shown near the notifications area.

In the vertical panel that appears, click More.

Select Settings from the context menu that appears.

image

In the window that opens, jump to the tab Auto Save.

In the section Protect your important foldersclick on the button Update folders.

image

The OneDrive window will show you folders Desktop, Documents and Pictures. Make sure that each of them is selected (it can be seen by the darker color of the folder and a tick mark). If necessary, select each folder.

When its done, click on Start protection.

image

When you complete these steps, documents and other files stored inside each of the said folders will be safely uploaded to OneDrive cloud service from your account.

How to protect your Windows 10 laptop from fraudsters and viruses


To ensure security of your laptop and all the information you have on it, you can always use third-party solutions from trusted developers and antivirus software that offer both free products for basic protection and advanced commercial solutions providing multi-level and varied protection security options within a single software complex. However, the latest operating system Windows 10 comes supplied with a powerful antivirus and firewall which are perfectly sufficient to protect your computing device and its files against various viruses, other malware and hacking attempts.

Run a full scan for viruses with Windows Defender


The built-in antivirus inside Windows 10 is enabled by default and ready to protect your laptop against almost every kind of malware, including viruses, spyware and ransomware. However, it is recommended to run a full scan from time to time and check your computer for hidden malware, especially if you notice a significant slowdown in how the laptop works and processes data.

To run such a scan meant to detect and remove malware from your computer, take the steps described below:

Open the Windows 10 antivirus in any way you prefer. For example, open the Settings app in any way you like, and scroll down until you see Update & Security.

image

In the left-side panel, select Windows Security, and then jump to Open Windows Security on the right.

image

Otherwise, open the main Windows menu by clicking on the Start button in the lower left corner of your desktop, on the Taskbar. Scroll down the list of installed apps and system services to find and select Windows Security.

image

In the main page of your security center, click on Virus & threat protection.

image

In the Current threats section click on the link Scan options.

image

The service will display available scan types. Check the option for Full scan to run a full-scale virus check.

Then hit the button Scan now to start detecting and isolating any malware that your computer may contain.

image

Windows Defender will scan the laptop and remove any elements that its internal security system believes to be malicious.

Enable Windows Firewall


As an additional security tool to improve computer protection, Windows 10 also includes Windows Firewall, whose main goal is to restrict unauthorized access of third parties to user networks; in other words, it filters network data streams to make sure no one gets to control your PC or modify or steal your data.

This built-in firewall should be enabled by default. If it isnt, you can always turn it on by taking these steps below:

Open the Windows Security service in any way you know (or any way we described in this article).

In the security overview page, select the tab Firewall & network protection.

image

In the related page, click on the button Restore firewalls to default.

image

After that, the firewall will operate in a full-featured mode and protect your device and data from all kinds of network threats.

If you are using a third-party antivirus and firewall, visit their developers website for more information on how to enable and manage these products.

See the full article with all additional video tutorials.
Подробнее..

Перевод Метаморфоза NetApp как ведущий поставщик систем хранения превратился в поставщика облачных технологий

16.11.2020 14:12:10 | Автор: admin
На ежегодной конференции NetApp Insight и последовавшей за ней Cloud Field Day 9 (CFD) компания NetApp представила новые продукты и рассказала о стратегии компании на будущее. Кроме прочего, NetApp анонсировала множество новых проектов, связанных с мультиоблачными решениями.




Полноценный переход к Data Fabric


Когда-то компания специализировалась только на решениях, в основе которых была ONTAP собственная операционная система компании для хранилищ данных, таких как NetApp FAS и AFF. Однако несмотря на то, что система действительно хорошо работает, ее невозможно применить ко всем новым продуктам NetApp. Это мешало развитию новых решений.

В 2019 году NetApp рассказала об изменениях в стратегии развития и выпуске новых продуктов на основе Data Fabric (фабрика данных) это единый комплекс из технических и программных компонентов, который помогает организациям управлять данными в гибридных и мультиоблаках, объединять локальную и облачную инфраструктуру. Такие решения упрощают управление большими массивами данных и интеграцию облачных технологий для заказчиков.

Это было стало большим шагом вперед для компании. NetApp начала разрабатывать такие продукты, как объектное хранилище StorageGrid, купила компанию Solidfire, интегрировала различные семейства продуктов, чтобы все работало вместе, и добавила дополнительные инструменты, чтобы упростить жизнь своим клиентам. В конце концов, ONTAP перестала быть единственным ответом на все вопросы, и компания стала двигаться вперед.

Облако, построенное на основе Data Fabric


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

После Insight и CFD, обновление стратегии кажется завершено. Можно сказать, что NetApp сегодня является одним из наиболее развитых провайдеров на рынке гибридных технологий. Проекты Astra или даже новый VDS (Virtual Desktop Service) используют в основе Data Fabric.

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

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

Компания создает набор интересных решений на основе надежных и согласованных методов управления данными. С определенной точки зрения эта стратегия похожа на стратегию VMware: их стек теперь доступен во всех облаках, а на его основе построены дополнительные решения (например, Disaster-Recovery-as-a-Service или послеаварийное восстановление как услуга, появившийся в результате приобретения Datrium).

Что в итоге


Можно ли по-прежнему классифицировать NetApp как традиционного поставщика систем хранения? Определенно доходы от продажи систем хранения данных по-прежнему составляют львиную долю их доходов (так что они все еще традиционные в этом плане), но изменение стратегии здесь весьма заметно, и доходы от облачных вычислений становятся все более внушительными.

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

Важно отметить, что с этой точки зрения NetApp не одинока (мы уже упоминали VMware). Аналогичной стратегии придерживаются и у других компании, такие как RedHat. Все они хотят создать единый пользовательский интерфейс независимо от того, где клиент развертывает свой бизнес (и данные).

Прогноз


Сможет ли NetApp снова измениться? Будет ли это надежный поставщик облачных услуг и станет ли компания настоящим поставщиком гибридных облачных хранилищ? Компания хорошо справилась с переходом на Data Fabric и находится на правильном пути, чтобы повторить успех. Сравнивая NetApp с некоторыми другими традиционными поставщиками систем хранения, у них действительно хорошие возможности расширить список услуг и закрепится на рынке облачных технологий.



Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:



Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru