Комментарии 56
У меня где-то валяется парочка двухпортовых FC-карточек, доставшихся совсем за копейки, на которых можно получить те-же 4Гбит/с, но при этом можно построить почти взрослую SAN-сеть…
Опять-же, с точки зрения «недорого» — RAID или HB[A]-контроллер выйдет всяко дешевле отдельной конфигурации под FreeNAS с ZFS, которая и проц и память кушает как не в себя…
Ну а так, если бороться за скорость и дешевизну — то проще с иБея назаказывать б/у SSD интел/самсунг/микрон из старых серий…
Всё, из чего состоит FreeNAS — просто "валялось под ногами", а в процессе вылезли некоторые интересные вещи, которыми буду делиться. Ну и сама сеть — решающий выбор, на 10G нет особо задач. Так что FC не взял бы даже даром, а уж найти FC-коммутаторы "для "почти взрослой SAN"… Карточку RAID проще, тут согласен. Однако я бы предпочёл иметь возможность повторить технологию размазывания своих данных по нескольким шпинделям. Иначе результат не заставит себя ждать. Так что карточек должно быть больше, чем 1шт, а ZFS пул при необходимости восстановления — спокойно собирается в любом аппаратном окружении.
а уж найти FC-коммутаторы «для „почти взрослой SAN“Зачем коммутатор(ы)? Две карточки, двухпортовые — одна в ESXi, вторая во FreeNAS. И у FC меньше прослоек по-сравнению с iSCSI, например…
— локальный RAID можно только с контроллером, который есть в hardware compatibility list
— контроллер без запитанного кэша — деньги на ветер;
— контроллер без второго контроллера — данные на ветер;
— к хранилке по сети можно легко и непринуждённо подключить ещё один гипервизор
— к бэкапам надо относиться ответственно и на что попало их не складывать ))
— к хранилке по сети можно легко и непринуждённо подключить ещё один гипервизорТо-же через четырехпортовую сетевую карту? А 16-портовый управляемый коммутатор в смету входит или то-же «под ногами валяется»?
— к бэкапам надо относиться ответственно и на что попало их не складывать ))т.е., хранилку собрать из того, что «валялось под ногами» — это ОК, а бэкапы туда складывать — уже "надо относиться ответственно и на что попало их не складывать"? Ну ОК, норм, чё…
Если говорить о возможности — то не обязательно тоже по 4м портам, и уж тем более не обязателен управляемый 16п-коммутатор. Для тестов вполне достаточно любого гигабитного, отданного целиком под сеть хранения. Я больше скажу — вот та сборка на E5450 просто не тянет 4 порта, поэтому можно спокойно располовинить адаптер хранилки на два потребителя.
Для тестов вполне достаточно любого гигабитного, отданного целиком под сеть хранения.И у любого гигабитного не снесет крышу от того, что четыре его порта идут в один и тот-же сервер, пусть и с разными [МАК и] ИП-адресами? Это какая-то ESXi/BSD/Linux-магия?
PS: Мне всегда казалось, что если надо подключиться к коммутатору через несколько сетевых портов — то обязателен, как минимум, Web-управляемый коммутатор с тимингом. Есть другие варианты?
А что ему, коммутатору, сделается? Нормальный коммутатор даже просадки скорости не даёт. Это не магия, это обычный multipath. В статье эти настройки даже с иллюстрациями, кстати.
Да, для прода лучше управляемые свитчи, и то, для нарезки VLAN по подсетям путей и изоляции SAN-трафика.
Потребуется выделить 4 интерфейса VM Kernel, принадлежащих 4м разным порт-группам в 4х разных виртуальных коммутаторах. Каждому из этих коммутаторов выделяем свой физический порт аплинка.Попробуйте это всё в один виртуальный коммутатор засунуть, а потом рассказать про multipath получившийся…
Вы немного путаете теплое с мягким. MPIO разруливается на стороне OS сервера. В данном случае гипервизора. И коммутаторы тут как бы остаются не при чем. Правда и сетевую карту лучше иметь с поддержкой iSCSI инициаторов, а не использовать софтовый.
И что касается тиминга и агрегации, то в случае iSCSI они скорее вредны, чем полезны. Так как MPIO гарантированно равномерно разложит нагрузку по всем активным физическим путям, в отличии от агрегированных интерфейсов.
Вы немного путаете теплое с мягким.Я, как-бы, и не утверждаю, что я гуру в этом вопросе, но
MPIO разруливается на стороне OS сервера.(MPIO — это multipath IO?) тут я полностью согласен, но MPIO работает поверх чего-то, например, TCP/IP, Ethernet, etc? И вот на этих-то уровнях будут проблемы при наличии одного неуправляемого коммутатора, насколько мне позволяют понять мои имеющиеся знания. Поэтому я и не согласен с тем, что
И коммутаторы тут как бы остаются не при чем.
Однако, я прочитал MPIO vs LACP и согласен,
что касается тиминга и агрегации, то в случае iSCSI они скорее вредны, чем полезны.В данном случае, при необходимости подключения третьего устройства (т.е. два гипервизора к одному СХД) и при необходимости железного коммутатора вместо тиминга, агрегации
PS: Если неправ — прошу поделиться ссылками на почитать в чем неправ.
Вот тут нужно опять же разделить мух и котлеты. Я не имею ничего принципиально против управляемых коммутаторов :). Но если по теме статьи, цель автора, как я его понял, была собрать стенд для экспериментов. И в данном случае чем проще и дешевле, тем лучше. Можно для третьего сервера и еще одну сетевую карту воткнуть. И с неуправляемым коммутатором я тут особых проблем не вижу. Ну будет с его точки зрения подключено какое-то количество неизвестных ему устройств, каждое из которых имеет свой mac и IP. Ну обмениваются они по TCP/IP какими-то пакетами. С какого IP и физ.интерфейса слать следующий пакет решается на стороне multipath I/O на сервере.
Если же говорить о нормальном продуктиве, то не думаю, что кто-то в здравом уме решиться использовать FreeNAS под хранения виртуалок, т.к. точкой отказа тут сразу будет сам сервер/компьютер, на котором это поднято. Если использовать для сети хранения данных iSCSI, то опять же для отказоустойчивости нужны будут минимум две отдельных физических фабрики. Каждая из которых состоит как минимум из одного коммутатора. В идеале в этих фабриках не должен бегать трафик пользователей (от серверов к клиентам), а значит VLAN не понадобятся.
Почему отдельные коммутаторы и две фабрики под iSCSI? Причин может быть несколько. Начиная от упрощения конфигурирования, обслуживания и замены неисправных до улучшения общей производительности, за счет отсутствия пользовательского трафика. Наиболее простой пример, если накосячить с изменением конфигурации и прервать доступ пользователей к серверам, то будет не приятно, но не смертельно. А вот если на ходу случайно у гипервизора оторвать датастор с виртуалками, то есть не нулевая вероятность, что не все виртуальные машины и сервисы на них смогут пережить такое отношение.
Вот тут нужно опять же разделить мух и котлеты.Вот да! У нас тут про «домашнюю виртуализацию» тема, как автор статьи подтвердил, а Вы со своим энтерпрайзом…
Я просто пытался расширить ваш кругозор, простите глупого :).
Все ухожу дальше кроваво энтерпрайзить… :)
За энтерпрайз — нет!
Ну и энтерпрайз бывает очень сильно разный: у кого-то банк, а у кого-то минимаркет — и время приемлимого простоя у каждого своё!
PS: Я не думаю что кто-то в энтерпрайзе будет поднимать хранилище ВМ через iSCSI на FreeNAS — есть другие бесплатные решения именно для энтерпрайза.
В конкретном случае профит multipath как раз в одновременной утилизации всех линков. Я намеренно не пишу "агрегации", дабы не вводить Вас в заблуждение. LACP здесь вообще никаким боком не стоял.
P.S. выше вот уже написали по существу.
P.S. выше вот уже написали по существу.
Там-же и ответил, но так-же хочу повторить и здесь, что, с моей точки зрения, всё-равно понадобится управляемый коммутатор, только для VLAN'ов, а не тиминга/агрегации, в случае подключения второго гипервизора к СХД через коммутатор…
PS: Если неправ — прошу поделиться ссылками на почитать в чем неправ.
Еще, я тут погуглил и внезапно осознал, что ESXi не может в software RAID. Не знал.
А представляете, был бы KVM можно было бы просто mdadm и сеть не собирать…
Про offload я чё-то и не вспомнил, хотя симптом вполне предполагал копать туда: на некоторых нагрузках четырехпортовый i350 просто топит проц в прерываниях. Спасибо, надо будет сравнить.
Насчёт jumbo — основывался на рекомендациях (в т.ч. самой VMWare), с учётом сказанного выше — действительно, был некоторый эффект.
NFS предполагает доступ файлового уровня и тоже по-своему хорош. На нем можно развернуть гостей, нетребовательных к дисковой производительности.
Как вариант, для подключения гостей, можно и Samba использовать, у нее так же есть multichannel с помощью нескольких интерфейсов, причем настраивать вообще ничего не нужно(ну кроме включения самого multichannel в конфиге, если не включен). Правда тоже не супер универсально, та же mac os, к слову, до сих пор multichannel не умеет.
Что мешает решать вопрос с RAID (сохранностью данных) на уровне самих виртуальных машин? Почти все современные OS умеют софт-рэйд. На VM с двумя vmdk, раскиданными на два локальных физических диска (датастора), можно организовать тот же Raid1. При наличии большего количества локальных дисков и типов используемых OS можно и другие типы софт-RAID сделать. Необходимость в железке под FreeNAS отпадает.
Что касается описанного в статье подключения по iSCSI, то хорошо бы обратиться к статьям VMware.
1) Выключить DelayedACK: https://kb.vmware.com/s/article/1002598
2) Adjusting Round Robin IOPS limit from default 1000 to 1: https://kb.vmware.com/s/article/2069356
3) Setting the Maximum Outstanding Disk Requests for virtual machines: https://kb.vmware.com/s/article/1268
Да, очереди и уменьшение (для слабого железа) iscsivmk_LunQDepth чуток помогают. С мыслями соберусь — напишу ещё по этому поводу.
Что мешает решать вопрос с RAID (сохранностью данных) на уровне самих виртуальных машин?
Никогда не считал этот вариант приемлемым.
Никогда не считал этот вариант приемлемым.
А причины есть?
У меня домашние сервисы на HP Microserver Gen8 несколько лет именно в таком режиме и крутятся. Два диска и VMware на microSD. Все что совсем не хочется потерять живет на софт рэйд (для обеспечения доступности в случае потери физ. диска) + периодический авто-бэкап на стационарник.
Ну тут скорее от задач зависит. Так что я не совсем согласен про противоречие концепции виртуализации. Если хочется избежать лишних трат во внепромышленной эксплуатации, то почему нет? В разрезе виртуализации, проблем при одиночном хосте тоже нет. На одной физ. машине размещается несколько виртуальных, повышая утилизацию и экономя средства на железо. С переносимостью виртуалок в другое место проблем тоже особых не будет. Без кластера и покупки лицензий в online этого не сделать, да и вряд ли будет такая потребность. С простоем сервисов перенести на другое железо совсем не проблема. Как-то так.
PS: И если не затруднит — и это не секрет какой-нибудь — можно конфиг Вашего «бытового гипервизора» узнать? Особенно мать интересует…
Так-то и Hyper-V — тоже вполне подходит ))
ESXi на маленьких конфигурациях все же менее прожорлив. Да и танцев с бубуном нет с ним. Когда сервер всего один. С Hyper-V все несколько тяжелее и сложенее.
Плюсом есть кластер, репликация, миграция и бекапы родными средствами
И это на одном физическом сервере? :)
Hyper-V на маленьких конфигурациях тоже не сложен.
Ну и почитав вот тут: https://serveradmin.ru/ustanovka-i-nastroyka-windows-hyper-v-server-2016/ не назвал бы установку и настройку Hyper-V абсолютно интуитивно понятной и простой :). В ESXi настройка сводиться практически к прохождению одного простого визарда и ожиданию окончания установки.
И это на одном физическом сервере? :)Если железо позволяет, то можно поставить гипервизор, а в нем еще два-три гипервизора и софтСХД. Для тестовой среды — вполне ок и ВМваря так умеет. Вот конкретно про ESXi, конечно, сомневаюсь…
Где памяти-то столько взять на домашнем сервере? И дискового пространства под винду Hyper-V? :)
А про ESXi не сомневайтесь :). Вложенная виртуализация давно поддерживается.
Где памяти-то столько взять на домашнем сервере?Столько — это сколько?
Тут конфиг обсуждается с 64 гигами — это мало под тестовую среду?
Вложенная виртуализация давно поддерживается.Именно на бесплатном ESXi? «Бесплатном» в соответствии с лицензией, а не «не хочу — не плачу, всё и так работает»? Ну ок, но перекосы странные, кмк…
А про ESXi не сомневайтесь :). Вложенная виртуализация давно поддерживается.Вот не зря сомневался — тут пишут что:
1) Вложенная виртуализация не для энтерпрайза! (за единственным исключением)
2) Таки не бесплатно: требуются дополнительные лицензии даже в случае бесплатного ESXi.
Лицензии для постоянного использования вложенных гипервизоров нужны. А вот на сделать лабу и поиграться я думаю дефолтного двухмесячного триала должно быть достаточно.
Ну и согласен, что погорячился. Но тем не менее оффициально не поддерживается и не работает — это не одно и то же.
https://www.vmgu.ru/news/vmware-nested-esxi-content-library
Ну и вот тут.
С вашего позволения, на все неотвеченные вопросы здесь, внизу напишу.
У нас у всех разные представления о простоте. Кто-то вот, к примеру, в 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, когда оно измеримо, определяемо и принято всеми сторонами процесса — уже вполне себе такой энтерпрайз.
А у вас везде всё строго задублировано, кластеризовано и вендор готов в три часа доставить запчасть со склада?
На работе именно так :). Правда с 3 часами на доставку запчасти это перебор, если вы конечно не в Москве и готовы платить за эту оперативность. NBD вполне достаточно.
Что касается домашней инфраструктурки, то тут все в меру возможностей и здравого смысла.
Экономим на RAID-контроллере, или как накормить Варю иопсами