Имеется Raid adaptec ASR-6805E закупался под цели сервера помойка файла хранилища на множество дисков. Установил появились проблемы, с опознанием дисков. Решил прошить последней прошивкой с сайта производителя. После чего вообще перестал определятся, в системе, как устройство, пробовалось на разных ОС от nix-ов до win11, не видит, а откат на пред прошивку не получается, потому что по глупости бэкап не сделан. А версию ниже просто не дает установить. Ссылаясь что у вас прошивка лучше и новее..
Вопрос в том, как прошить контроллер через инженерную консоль, там есть на плате гребенка конвекторов для подключения и работы через туже Puty. Эти крохи инфы нашел на далеких забугорных форумах, через боль и страдания с VPN.
Как вообще выйти из это ситуации.
прошит был версией 6805e_fw_b19204. Прошивался через DOS утилиту.
ASUS TUF GAMING A620M-PLUS: Установил МП, сделал RAID 1 из 2 SSD, но при создании пространство конвертируется в MBR и последующая конвертация в GPT разрушает RAID. Но при разметке MBR система не устанавливается. И даже установка дискретной видеокарты и включение CSM режима не помогает - в этом случае после выбора загрузочного устройства чёрный экран с мигающим курсором. При загрузке в Legacy отключал Fast boot. Secure boot в OS type стоит Other OS. Вопрос - как поставить систему любым способом (UEFI или Legacy)?
После того как я прикупил себе RAID контроллер Adaptec 71605
и решил заново установить на Dell OptiPlex 990 SFF гипервизор ESXi, что-то пошло не так, а именно сборка образов и прочая чёрная магия в течение нескольких дней не принесли ожидаемого результата, то установщик не узнаёт мой сетевой адаптер:
то не видит RAID контроллер, то все вместе, а то вдруг все видит, но на этапе установки ругается на мои вшитые в образ VIB с драйверами ссылаясь на какие-то зависимости:
Этот момент мне несколько поднадоел и решил я в качестве эксперимента накатить последнюю версию Proxmox, вот как есть, без каких-либо изменений и она без проблем установилась на текущую конфигурацию, увидела и RAID контроллер и сетевую карту, да всё настолько легко прошло, что я решил перенести на неё все мои виртуалки. Собственно сам перенос из файла .ovf выполняется одной единственной командой qm importovf 103 /home/Win11/Win11.ovf local-lvm:
qm importovf 103 /home/Win11/Win11.ovf local-lvm
103 - идентификатор VM, /home/Win11/Win11.ovf - путь к файлу .ovf, local-lvm - путь к хранилищу на гипервизоре proxmox
В случае с Windows импорт я делал прямо из .ovf файла который получил путем экспорта с ESXi, там было достаточно заменить scsi0 на sata0 в конфигурационном файле /etc/pve/qemu-server/103.conf и добавить сетевой адаптер.
В итоге ОС запускается и работает без проблем:
А вот в случае, когда я переносил машину Debian с Home Assistant, первоначально у меня она была перенесена из .ovf в VMware Workstation, поскольку, пока я копался с настройкой Proxmox, надо было чтобы HA продолжал работать, затем когда всё готово было к переносу, я сделал экспорт Debian с HA и затем экспорт уже на Proxmox, всё завелось с полпинка, даже после проброса USB ZigBee Sonoff 3.0 dongle - не пришлось колдовать с Zigbee2MQTT, он заработал сразу. На волне успеха побежал импортировать свою виртуалку с Debian, которая с такой же лёгкостью не поднялась, а дело было в том, что на VM с HA у меня был BIOS, а на второй UEFI, тут то и зарылась проблема, понял я это не сразу и даже потратил немного времени, перенес виртуалку сначала в VMware Workstation, оттуда сделал экспорт, затем импорт в Proxmox и ничего не заработало, но оно и не удивительно. Теперь конкретнее, что необходимо было сделать если вы переносите таким способом VM Debian UEFI. После выполнения импорта на гипервизор в настройках виртуалки:
в разделе hardware поправим BIOS на UEFI и SCSI Controller меняем на VirtIO SCSI
в options => boot order отмечаем первым пунктом наш диск
Сетевой адаптер добавить не забываем, они всегда слетают после импорта.
Далее необходимо запустить виртуалку и в консоли сразу же нажать ESC чтобы попасть в настройки UEFI, пройти по пути:
Boot Maintenance Manager =>
Boot Options =>
Add Boot Option =>
выбрать диск с EFI загрузчиком (он там будет единственный в большинстве случаев)
Далее пройти по пути до самого загрузчика:
(в случае с Debian - это shimx64.efi) выбрать его
зайти в меню Input the description вписать любое название для загрузчика
например debian
подтвердить нажатием Commit Changes and Exit
Далее изменить загрузку по умолчанию:
зайдя в меню Change Boot Order
там нажимаем Enter и плюсиком перемещаем debian на первый пункт и нажимаем Enter
подтвердить нажатием Commit Changes and Exit
нажимаем Reset
виртуалка перезагрузится
и вы должны будете увидеть Grub и успешно загрузиться в Debian
Кому интересна тематика умного дома, прошу в мой телеграмм канал, там регулярно пишу о своих идеях, сценариях, реализациях и прочих темах DIY, IoT, CS.
Случайно удалил том диска raid 0 массива. В массиве было 2 диска, сейчас отображаются оба с не размеченной областью. Новый том и разметку не создавал, на диски ничего не записывал. Кто знает, подскажите, пожалуйста, как восстановить том/вытащить данные из дисков? Пожалуйста, только конкретную информацию кто имел подобный опыт. Спасибо!
Как пелось в одной песне - We're going down, down, all the way down We're heading deeper down going down > Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
Все началось с того, что мне прислали очередную ссылку на разговор в российской майнинг-группе. Некий юзер начал плакать – как так, у меня NVME не дает в raid больше 100к IOPS, как страшно жить, ведь отдельный Samsung обещает : Samsung 980 Pro SSD Random Write 4K QD32 Up to 1,000,000 IOPS Samsung 990 PRO - while 4TB even higher random read speed of up to 1,600K IOPS.
Samsung обещает. Не забывая про то, что там стоит памяти 4 гб - Samsung 4GB Low Power DDR4 SDRAM Но есть нюанс. Давать то дает, но не под постоянной нагрузкой, и поэтому для бизнес-задач с нагрузкой 24*7 не годится – будут непредсказуемые падения скорости, когда контроллер решит заняться внутренними операциями.
Дальнейшая дискуссия между сторонами показала, что ни ноющему, ни основному составу майнинг-группы не понятно, зачем ему нужно именно столько, и куда он будет их девать.
Я, в свою очередь, очень удивился – откуда у людей руки растут. Пошел спросил результаты тестов у других коллег на одиноких NVME, без всяких железных raid. Seq WR, все такое.
Блок 4к, зеркало, очередь 16 , 100% чтение – 1600к IOPS Блок 4к, зеркало, очередь 16 , 70/30 чтение – 850k IOPS на чтение, 350k IOPS на запись Блок 64к, зеркало, очередь 16 , 100% чтение – 650к IOPS Блок 64к, зеркало, очередь 16 , 70/30 – 250k / 100 k IOPS Блок 64к, зеркало, очередь 16 , 100% запись – 150 k IOPS
Результаты, конечно, не показательны - разве что для того, чтобы было с чего разговор начинать. Значимо (в 1.5 раза) влияет и число потоков на файл (точнее, соотношение числа ядер процессоров и потоков на файл – как пишут в руководствах, In general it is recommended to use 1 CPU for testing and use the same number of threads), и количество файлов, точнее используемых в тесте разделов, и тонкие или толстые диски, и так далее. В тестах выше был MS Server 2019, это тоже имеет значение – в MS Server 2025 обещали улучшить работу с NVME
На все это намазывается не только размер блоков, но и число выделяемых дескрипторов\очередей \прочего (внутри СХД, внутри системы, внутри везде, как тех же буферных кредитов – от которых можно получить Slow-Drain), особенно если у вас не локальные диски, а СХД. И все равно в реальном мире можно нарваться на, цитата:
Setup: Dorado 18000, iSCSI, ESXi 7.0.3 (2x25Gb)
На виртуальном диске 100 ГБ запускаю нагрузку FIO 70% read, IO Size 32 KB, вижу на datastore и на dorado одинаковый Read IO Request Size 32 KB.
На виртуальном диске 1024 ГБ тот же тест, та же нагрузка. На ВМ вижу 32 KB, на Datastore уже 25-26 KB на чтение. Запись идёт так же 32 KB. На Dorado соответственно тоже видно на чтение блок стал 25-26 KB.
Решение: Причина мультипликации IO и несоответствия размеров блоков установлена!
Проблема возникает при превышении объёма в 32 ТБ открытых VMDK файлов на хосте.
Накладные IO вызваны нехваткой кэша указателей блоков для открытых vmdk файлов.
Этот кэш необходим для быстрого обращения к открытым блокам VMFS без дополнительного доступа к метаданным из файловой системы.
При утилизации кэша больше 80% включается механизм вытеснения блоков указателей.
Вытесняются наименее активные блоки указатели и включаются (с чтением метаданных с vmfs) новые блоки. Отсюда возникает полученный нами overhead, т.к. нагрузочное тестирование, что FIO, что vdbench запрашивает блоки хаотично и по всему объёму.
Размер кэша задаётся advanced параметром:
VMFS3.MaxAddressableSpaceTB = 32 - Maximum size of all open files that VMFS cache will support before eviction mechanisms kick in
Его максимальное значение 128. При установке 128 - проблема с накладными IO в тестах уходит. Можно для целей тестирования выставить его в 128.
Увеличение кэша ведёт к накладным расходам по памяти, при значении по умолчанию 32 используется 128 МБ памяти. При максимальном значении 128 используется 512 МБ оперативной памяти.
В прод нагрузке вряд ли стоит увеличивать этот кэш, но посмотреть по хостам можно занятые объёмы кэшей командой:
esxcli storage vmfs pbcache get
В реальной жизни нет нагрузки со 100% активными блоками, как в синтетических тестах. Если, к примеру, активны только 20% всех блоков открытых VMDK и их указатели, соответственно попадают в кэш, то мы сможем иметь 160 ТБ открытых VMDK на хосте, при этом активные блоки указателей по-прежнему кэшируются без особого снижения производительности.
Поэтому ответ на исходный вопрос «Но хотя-бы 400k IOPS почему никак не вытаскиваются из одного сервера с 10 дисков-то?» - простой. Наймите специалиста, если сами не можете. Все вытаскивается.
Дальше мне стало интересно, что же используют чуть более богатые фирмы, которые могут себе позволить потратить денег. Оказалось, достаточно много всего, но, как всегда – есть нюансы.
Пропустим ту часть, где обсуждается «зачем столько». Сын маминой подруги сказал что можно, и дальше по классике - НЕТ ДЕНЕГ НЕТ @ НЕТ Я АДМИН @ Я НИЧЕГО В ЭТОМ НЕ ПОНИМАЮ @ ЭТО ГОСКОНТОРА ВЗЯЛИ МЕНЯ
Проблема применимости, про нее не стоит забывать. Если у вас хотя бы 3-4 сервера с дисками, то зачем вам локальный RAID при наличии S2D и vSAN? Что с S2D, что с vSAN на 6-8 серверов можно получить 1-5 миллионов IOPS на чтение блоком 4к, при этом имея (с оговорками) и erasure coding, и, для S2D, ReFS Mirror-accelerated parity, и Data Deduplication, и в vSAN тоже много чего есть, и будет больше.
Но, к делу.
Что может выдать контроллер Broadcom MegaRAID 9670W-16i ? Посмотрим. Broadcom MegaRAID 9670W-16i RAID Card Review. Выглядит неплохо – до 240 SAS/SATA, до 32 NVME. Но, как только дело доходит до записи, все становится не так неплохо: для RAID 10 – Optimal 4KB Random Reads (IOPs) - 7,006,027 4KB Random Writes (IOPs) - 2,167,101
Но, есть нюанс. Broadcom MegaRAID 9670W-16i - Storage controller (RAID) - 16 Channel - SATA 6Gb/s / SAS 24Gb/s / PCIe 4.0 (NVMe) 05-50113-00 – 1500$.
В соседнем тексте упомянули Adaptec 3258upc32ix2s Cc 3258upc32ix2s Smartraid - 2000$. Тоже не очень дешевое решение для старого сервера.
With a single SupremeRAID™ card, users can achieve extraordinary results, boasting up to 28M IOPS and 260GB/s. Supporting up to 32 native NVMe drives, it empowers exceptional NVMe/NVMeoF performance while enhancing scalability, server lifespan, and cost-effectiveness. Supermicro and SupremeRAID™ Data Protection Solution
Performance results with SupremeRAID™ software version 1.5 on SupremeRAID™ SR-1010 2 миллиона IOPS в R5 на запись, пожалуйста.
Performance results with SupremeRAID™ software version 1.5 on SupremeRAID™ SR-1010
Но, есть нюанс. Graid SupremeRAID GRAID-1000 - 2600 $. Graid SupremeRAID SR-1010 - 4000 $.
Да при том. Graid SupremeRAID™ SR-1010 – это RTX A2000 (Ampere), и ее еще 70 ватт сверху, к и так не холодным NVME и CPU.
Вы, конечно, спросите, зачем это все?
И правильно сделаете. Идут такие решения, и подобное для тех, кому слишком дорого взять Nvidia DGX (Deep GPU Xceleration). Дело не только в «дорого». Набор для начинающих «по взрослому» - Nvidia DGX GB200 NVL72: 120 киловатт. 1.4 тонны. Водяное охлаждение. На 1 (одну) стойку. Поэтому Equinix уже год рассказывает, какие они молодцы, и они на самом деле молодцы – столько электричества подвести, и столько тепла вывести, это вам не стойки по 5 киловатт на луч продавать.
У кого же денег не просто много, а неприлично много, и так знают те три слова, что я узнал в сегодня лет: weka, vastdata, vast.ai.
Дэвид Паттерсон, Гарт Гибсон и Рэнди Кац из Калифорнийского университета в Беркли представили статью «Дело об избыточных массивах недорогих дисков (RAID)» в 1988 году, в которой утверждалось, что массив из нескольких недорогих дисков, предназначенных для приложений ПК, может превзойти один большой дорогой мэйнфреймовый диск.
Прототип FrankenRAID в Калифорнийском университете в Беркли (ок. 1992 г.)
Концепция зеркалирования уже была хорошо известна, и некоторые системы хранения уже были построены вокруг массивов небольших дисков, однако их аббревиатура (позже измененная на Redundant Array of Independent Disks) стимулировала интерес к подходу и привлекла коммерческих поставщиков.
RAID The First — состоял из 28 5,25-дюймовых SCSI-дисков (1989)
Новаторская работа, которая привела к RAID, включает зеркальное дисковое хранилище Tandem Computers в ее Non-Stop Architecture и зеркальные подсистемные дисковые накопители RA8X (теперь известные как RAID уровня 1) DEC в ее системах HSC50 и HSC 70 в начале 1980-х годов. DataVault Thinking Machines использовал коды исправления ошибок (RAID 2) в массиве дисковых накопителей. Накопитель IBM 353 использовал аналогичный подход в начале 1960-х годов. Патентные заявки инженеров IBM, Нормана Кена Оучи (1977) и Брайана Кларка и др. (1988) раскрыли методы, используемые в последующих версиях RAID. Ранние независимые поставщики RAID включают Adaptec и Array Technology, которая была основана в 1987 году и последовательно приобретена Seagate, Tandem и EMC.
Современная подсистема RAID
Развился ряд стандартных схем, называемых уровнями, каждая из которых имеет множество вариаций. Уровни RAID и связанные с ними форматы данных стандартизированы Ассоциацией индустрии сетевых систем хранения данных (SNIA) в стандарте Common RAID Disk Drive Format (DDF). Сегодня большинство серверных и сетевых хранилищ основаны на RAID, и многие пользователи ПК используют аппаратные или программные RAID-системы на своих собственных машинах.
