Хранение данных — это всегда боль, у которой может быть больше 50 оттенков: железо, кэш, гарантии, производительность, скорость восстановления при проблемах, удобство и прочее. Как решить большинство из них, при этом получив что-то легко обслуживаемое, да ещё бесплатно? Сегодня поговорим про файловые системы на примере не совсем дефолтной OpenZFS.
Читать полностью »
Всем привет. Как мы и обещали, погружаем читателей Хабра в детали производства российских аппаратных платформ для СХД Аэродиск Восток на процессорах Эльбрус. В этой статье мы пошагово опишем производство платформы Яхонт-УВМ Э124, которая в 5 юнитах эффективно вмещает 124 диска, может работать при температуре +30 градусов по Цельсию и при этом не просто работает, а хорошо работает.
Также 05.06.2020 мы организовываем вебинар, где подробно расскажем о технических нюансах производства СХД Восток и ответим на любые вопросы. Зарегистрироваться на вебинар можно по ссылке: https://aerodisk.promo/webinarnorsi/
На 31 декабря 2019 г. у нас 124 956 работающих жестких дисков. Из них 2 229 загрузочных и 122 658 с данными. В данном обзоре мы рассмотрим статистику по отказам среди жестких дисков с данными. Также рассмотрим 12 и 14 TB версии дисков и новые 16 TB, которые мы активно используем с начала четвертого квартала 2019 года.
На конец 2019 года мы мониторили 122 658 жестких дисков использующихся, для хранения данных. Мы убрали из расчета диски, которые использовались для тестирования и диски, у которых нет наработки ~5 000 диско-дней (на модель), в течение четвертого квартала. Таким образом, мы собрали данные на основе 122 507 жестких дисков. Таблица ниже отображает нашу статистику:
Уважаемое сообщество, эта статья будет посвящена эффективному хранению и выдаче сотен миллионов маленьких файлов. На данном этапе предлагается конечное решение для POSIX совместимых файловых систем, в том числе кластерных, и вроде бы даже уже без костылей.
Поэтому для этой цели я написал свой собственный специализированный сервер.
По ходу реализации этой задачи удалось решить основную проблему, попутно добиться экономии дискового пространства и оперативной памяти, которую нещадно потребляла наша кластерная файловая система. Собственно такое количество файлов вредно для любой кластерной файловой системы. Читать полностью »
Привет, читатели Хабра. Хотим поделиться крайне приятной новостью. Мы наконец-то дождались реального серийного выпуска нового поколения российских процессоров Эльбрус 8С. Официально серийный выпуск должен был стартовать аж в 2016 году, но по факту именно массовое производство началось только в 2019 году и на текущий момент выпущено уже около 4000 процессоров.
Практически сразу после старта серийного производства данные процессоры появились и у нас в Аэродиске, за что хотим отдельно поблагодарить компанию НОРСИ-ТРАНС, которая любезно предоставила нам свою аппаратную платформу Яхонт УВМ, поддерживающие процессоры Эльбрус 8С, для выполнения портирования программной части СХД. Это современная, отвечающая всем требованиям МЦСТ универсальная платформа Яхонт УВМ. На данный момент платформа используется спец.потребителями и операторами связи для обеспечения выполнения установленных действий при проведении оперативно — разыскных мероприятий.
На текущий момент портирование успешно завершено и уже сейчас СХД AERODISK доступна в варианте с отечественными процессорами Эльбрус.
В этой статье мы расскажем о самих процессорах, об их истории, архитектуре и, конечно же, о нашей реализации СХД на Эльбрусе.
Привет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.
Обновление!. В комментах один из читателей предложил попробовать Linstor (возможно, он сам над ним работает), так что я добавил раздел об этом решении. Еще я написал пост о том, как его установить, потому что процесс сильно отличается от остальных.
Если честно, я сдался и отказался от Kubernetes (во всяком случае, пока). Буду использовать Heroku. Почему? Из-за хранения! Кто бы мог подумать, что я буду больше возиться с хранилищами, чем с самим Kubernetes. Я использую Hetzner Cloud, потому что это недорого и производительность хорошая, и с самого начала я развертывал кластеры с помощью Rancher. Я не пробовал управляемые сервисы Kubernetes от Google/Amazon/Microsoft/DigitalOcean и проч., проч., потому что всему хотел научиться сам. А еще я экономный.
Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestНужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]При разработках устройств часто бывает необходимым хранить настройки вне рабочей программы. Еще лучше иметь возможность их модификации без использования специальных средств.
Рассмотрим вариант хранения в пожалуй самых распространенных микроконтроллерах STM серии F103. Способствовала распространенности также всем известная макетная плата Blue Pill
Имеющаяся в ней flash позволяет не только хранить и модифицировать настройки используя файловую систему FAT12 во внутреннем flash, но и организовать обновление прошивки.
Согласно документации в STM32F103C8T6 имеется 64К flash памяти. Однако практически во всех STM32F103C8T6 установлено 128К. Об этом также упоминается в разных источниках — обычно ставят на 64К больше. Такая «фича» позволяет использовать микроконтроллер как flash накопитель объемом 128К — 20К (системные нужды FAT12) — размер прошивки.
Многие энтузиасты, пытавшиеся использовать данный контроллер как накопитель flash, сталкивались с проблемой его использования в режиме файловой системы FAT12. Использовать для снятия/заливки образа диска получалось. А вот при работе как с файловым накопителем начинались проблемы.
Читать полностью »
Когда пришли оркестраторы контейнеров, вроде Kubernetes, подход к разработке и деплою приложений изменился кардинально. Появились микрослужбы, а для разработчика логика приложения больше не связана с инфраструктурой: создавай себе приложения и предлагай новые функции.
Kubernetes абстрагируется от физических компьютеров, которыми управляет. Только скажите ему, сколько надо памяти и вычислительной мощности, — и все получите. Ифраструктура? Не, не слыхали.
Управляя образами Docker, Kubernetes и приложения делает переносимыми. Разработав контейнерные приложения с Kubernetes, их можно деплоить хоть куда: в открытое облако, локально или в гибридную среду, — и при этом не менять код.
Мы любим Kubernetes за масштабируемость, переносимость и управляемость, но вот состояния он не хранит. А ведь у нас почти все приложения stateful, то есть им нужно внешнее хранилище.