Поддержу, не нужна такая глубокая вложенность. Из жизни: от хэша берутся два блока по 3 символа на каталоги, abc/def/filename. Занимая, на текущий момент, чуть больше 40 TB, эта структура содержит 3-5 файлов на каталог.
«Обратный индекс», то бишь ревизия всех файлов для сравнения фактического наличия с БД — занимает около 3х суток (zfs). Чем глубже — тем дольше. Ну и тюнинг файловой системы, конечно, не помешает.
Спасибо, познавательно.
В копилку "таки нужен": не так давно с удивлением открыл для себя, что нормы закона о защите прав потребителей не распространяются на юрлиц. Как минимум, в части гарантийных сроков, возмещений и прочих моментов… После этого понял, почему в одних местах к каждой b2b продаже, пусть копеечной, подписывают "договор поставки", а в других — нет, и не заставишь...
С вашего позволения, на все неотвеченные вопросы здесь, внизу напишу.
У нас у всех разные представления о простоте. Кто-то вот, к примеру, в 2018 году всё ещё локально дисковую ёмкость подключает и собирает в md… Кстати, All Proxmox VE versions does not support the Linux Software RAID (mdraid), как у них написано. А ESXi принятый по iSCSI том — вполне себе поддерживает, куча рекомендаций, best practices, опять же… Кто-то вообще уже до следующего этапа дорос, SDS и vSAN домашний. Кто-то предлагает многоуровневую вложенную виртуализацию и софтрейд внутри неё — пусть делает пробует, не возбраняется ).
По поводу "в здравом уме никто не будет..." А у вас везде всё строго задублировано, кластеризовано и вендор готов в три часа доставить запчасть со склада? Рад, отлично. Если любого из перечисленных пунктов нет — решение мало чем отличается от того же FreeNAS, Nexenta, чего-то linux-based или вообще самостроя. Есть риск отказа, есть RTO, когда оно измеримо, определяемо и принято всеми сторонами процесса — уже вполне себе такой энтерпрайз.
Бесплатные для энтерпрайза — только костыли, не? Всё оплачивается, либо это прямые расходы на решение и от вендора, либо косвенные на сотрудников, которые умеют в "бесплатные костыли", либо убытки от простоев.
В конкретном случае профит multipath как раз в одновременной утилизации всех линков. Я намеренно не пишу "агрегации", дабы не вводить Вас в заблуждение. LACP здесь вообще никаким боком не стоял.
А что ему, коммутатору, сделается? Нормальный коммутатор даже просадки скорости не даёт. Это не магия, это обычный multipath. В статье эти настройки даже с иллюстрациями, кстати.
Да, для прода лучше управляемые свитчи, и то, для нарезки VLAN по подсетям путей и изоляции SAN-трафика.
Если говорить о возможности — то не обязательно тоже по 4м портам, и уж тем более не обязателен управляемый 16п-коммутатор. Для тестов вполне достаточно любого гигабитного, отданного целиком под сеть хранения. Я больше скажу — вот та сборка на E5450 просто не тянет 4 порта, поэтому можно спокойно располовинить адаптер хранилки на два потребителя.
Да ну какой «энтерпрайз». Так, тестовый стенд в SOHO. Железо под ESXi: GA-X150M-pro / E3-1240-v6 / 64GB. Железо под FreeNAS: GA-G41M-s2pt / E5450 / 8GB / 4x Hitachi CLA362 500GB. И собирался NAS как раз под объединение дисковой ёмкости во внешнем RAIDе, пощупать-попробовать. Результаты вполне устроили, выбор сделан в пользу этой схемы, пойдёт в работу — железо будет другое.
профит от SSD ZIL несколько переоценивают. Если не включена принудительная синхронизация тома, и приложение не запрашивает fsync после IO — ZIL не участвует.
так не бывает ) после первый же отгруженного в Torrent фильма ARC должен занять явно больше 2 ГБ… Главный профит ARC — хранение метаданных файловой системы. Ну и чтение, разумеется. Если объём памяти ограничен — атрибут primarycache=metadata для ФС должен помочь. Содержимое самих файлов не будет вымывать из кэша структуру, соотв, ZFS всегда знает, где лежит тот или иной блок и куда положить новый.
Вопрос личных предпочтений и интересов. Провернуть те же изыскания в Proxmox я бы сходу не рискнул, пожалуй. Плюс, его на md надо ещё натянуть… VMWare мне привычнее.
Так-то и Hyper-V — тоже вполне подходит ))
Дома-то оно, может, и нормально, когда больше ничего нету. Но вообще это идёт вразрез с самой концепцией виртуализации. Обеспечение ресурсов, в т.ч. отказоустойчивых — это уровень гипервизора, не гостей.
Потому, что
— локальный RAID можно только с контроллером, который есть в hardware compatibility list
— контроллер без запитанного кэша — деньги на ветер;
— контроллер без второго контроллера — данные на ветер;
— к хранилке по сети можно легко и непринуждённо подключить ещё один гипервизор
— к бэкапам надо относиться ответственно и на что попало их не складывать ))
Про offload я чё-то и не вспомнил, хотя симптом вполне предполагал копать туда: на некоторых нагрузках четырехпортовый i350 просто топит проц в прерываниях. Спасибо, надо будет сравнить.
Насчёт jumbo — основывался на рекомендациях (в т.ч. самой VMWare), с учётом сказанного выше — действительно, был некоторый эффект.
Всё, из чего состоит FreeNAS — просто "валялось под ногами", а в процессе вылезли некоторые интересные вещи, которыми буду делиться. Ну и сама сеть — решающий выбор, на 10G нет особо задач. Так что FC не взял бы даже даром, а уж найти FC-коммутаторы "для "почти взрослой SAN"… Карточку RAID проще, тут согласен. Однако я бы предпочёл иметь возможность повторить технологию размазывания своих данных по нескольким шпинделям. Иначе результат не заставит себя ждать. Так что карточек должно быть больше, чем 1шт, а ZFS пул при необходимости восстановления — спокойно собирается в любом аппаратном окружении.
«Обратный индекс», то бишь ревизия всех файлов для сравнения фактического наличия с БД — занимает около 3х суток (zfs). Чем глубже — тем дольше. Ну и тюнинг файловой системы, конечно, не помешает.
Спасибо, познавательно.
В копилку "таки нужен": не так давно с удивлением открыл для себя, что нормы закона о защите прав потребителей не распространяются на юрлиц. Как минимум, в части гарантийных сроков, возмещений и прочих моментов… После этого понял, почему в одних местах к каждой b2b продаже, пусть копеечной, подписывают "договор поставки", а в других — нет, и не заставишь...
С вашего позволения, на все неотвеченные вопросы здесь, внизу напишу.
У нас у всех разные представления о простоте. Кто-то вот, к примеру, в 2018 году всё ещё локально дисковую ёмкость подключает и собирает в md… Кстати, All Proxmox VE versions does not support the Linux Software RAID (mdraid), как у них написано. А ESXi принятый по iSCSI том — вполне себе поддерживает, куча рекомендаций, best practices, опять же… Кто-то вообще уже до следующего этапа дорос, SDS и vSAN домашний. Кто-то предлагает многоуровневую вложенную виртуализацию и софтрейд внутри неё — пусть
делаетпробует, не возбраняется ).По поводу "в здравом уме никто не будет..." А у вас везде всё строго задублировано, кластеризовано и вендор готов в три часа доставить запчасть со склада? Рад, отлично. Если любого из перечисленных пунктов нет — решение мало чем отличается от того же FreeNAS, Nexenta, чего-то linux-based или вообще самостроя. Есть риск отказа, есть RTO, когда оно измеримо, определяемо и принято всеми сторонами процесса — уже вполне себе такой энтерпрайз.
Бесплатные для энтерпрайза — только костыли, не? Всё оплачивается, либо это прямые расходы на решение и от вендора, либо косвенные на сотрудников, которые умеют в "бесплатные костыли", либо убытки от простоев.
В конкретном случае профит multipath как раз в одновременной утилизации всех линков. Я намеренно не пишу "агрегации", дабы не вводить Вас в заблуждение. LACP здесь вообще никаким боком не стоял.
P.S. выше вот уже написали по существу.
А что ему, коммутатору, сделается? Нормальный коммутатор даже просадки скорости не даёт. Это не магия, это обычный multipath. В статье эти настройки даже с иллюстрациями, кстати.
Да, для прода лучше управляемые свитчи, и то, для нарезки VLAN по подсетям путей и изоляции SAN-трафика.
Если говорить о возможности — то не обязательно тоже по 4м портам, и уж тем более не обязателен управляемый 16п-коммутатор. Для тестов вполне достаточно любого гигабитного, отданного целиком под сеть хранения. Я больше скажу — вот та сборка на E5450 просто не тянет 4 порта, поэтому можно спокойно располовинить адаптер хранилки на два потребителя.
Так-то и Hyper-V — тоже вполне подходит ))
Да, очереди и уменьшение (для слабого железа) iscsivmk_LunQDepth чуток помогают. С мыслями соберусь — напишу ещё по этому поводу.
Никогда не считал этот вариант приемлемым.
— локальный RAID можно только с контроллером, который есть в hardware compatibility list
— контроллер без запитанного кэша — деньги на ветер;
— контроллер без второго контроллера — данные на ветер;
— к хранилке по сети можно легко и непринуждённо подключить ещё один гипервизор
— к бэкапам надо относиться ответственно и на что попало их не складывать ))
Про offload я чё-то и не вспомнил, хотя симптом вполне предполагал копать туда: на некоторых нагрузках четырехпортовый i350 просто топит проц в прерываниях. Спасибо, надо будет сравнить.
Насчёт jumbo — основывался на рекомендациях (в т.ч. самой VMWare), с учётом сказанного выше — действительно, был некоторый эффект.
Всё, из чего состоит FreeNAS — просто "валялось под ногами", а в процессе вылезли некоторые интересные вещи, которыми буду делиться. Ну и сама сеть — решающий выбор, на 10G нет особо задач. Так что FC не взял бы даже даром, а уж найти FC-коммутаторы "для "почти взрослой SAN"… Карточку RAID проще, тут согласен. Однако я бы предпочёл иметь возможность повторить технологию размазывания своих данных по нескольким шпинделям. Иначе результат не заставит себя ждать. Так что карточек должно быть больше, чем 1шт, а ZFS пул при необходимости восстановления — спокойно собирается в любом аппаратном окружении.