1 2 Previous Next 23 Replies Latest reply on Jun 3, 2013 7:30 AM by Sladky Branched to a new discussion.

    Какой размер кластера выбрть для ESXi 5.1 при построении RAID

    unix111 Enthusiast

      Планируется Ввести сервер в экспулатацию Supermicro X7DW3   2@xeon 5405  16 gB RAM
      HDD 8    1TB hitachi 7.200 sata
      Raid Adaptec 5805
      Планируется задействовать Raid 10  6hdd  2hdd hotspare
      на сервере будет крутится серверы терминалов   Файлопомойка  серверы MsSql 2008 r2
      Windows 2008 r2   windows 2003 r2

      Собственно вопрос какой  Размер блока выбрать При создании дискового масива
      доступны размеры 64  256  1024 kb
      Посоветуте наиболее оптимальный вариант для этой конфигурации

        • 1. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
          Sladky Master

          Я на практике использую 1024 и производительностью доволен.

          Причина - размер кластера в VMFS5 = 1 MB

           

          Буду рад выслушать за и против со стороны коллег.

          • 2. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
            urbas Hot Shot

            всегда думал, что операции ввода-вывода гостевых систем направляются напрямую san/scsi блочному устройству. То есть размер блока VMFS не влияет, систему хранения надо проектировать под потребности гостевых систем. 

             

            • 3. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
              Sladky Master

              Команды "напрямую" передаются только в случае RDM дисков, хотя и там гипервизор вмешивается.

              При использовании VMFS все команды от гостя перехватываются. интерпритируются кернелом под формат гипервизора и потом уже передаются на VMFS. И вот тут соотношение размера кластеров VMFS и RAID могут влиять.

               

              Про 2 хотспары - тоже удивило несколько.

              • 4. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                urbas Hot Shot

                точнее да, не "напрямую". Но размер кластера вмфс всё-равно не влияет, т.к. используется адресация суб-блоков, а размер суб-блока в 5вмфс - 8кб. Оптимизировать надо под гостевую ос/приложение

                • 5. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                  unix111 Enthusiast

                  Значит  вы рекомендуете использовать все 8 дисков под 10 raid без хотспары?

                  • 6. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                    urbas Hot Shot

                    ага

                    если сильно беспокоитесь, лучше ещё один диск потом докупите. Если в сервере некуда вставить, просто рядом положите) не очень хот получится, но всё-же спаре. Ну и про бэкапы не забывайте, диски дисками, а бывает и такое, что контроллер может выйти из строя и все диски за собой потянуть. А вообще очень маловероятно, что 2 диска из одного зеркала одновременно выйдут из строя. Используйте все диски под данные, только настройте оповещение себе на почту куда-нибудь в случае проблем с железом

                    • 7. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                      Sladky Master

                      Ничего не берусь утверждать, но я 10-й рэйд из 16 дисков юзаю без хотспаров. Настроено оповещение.

                       

                      И по скорости, даже 5-й рэйд на SAS 10k уделывает 10-ку на SATA. причем уделывает по всем параметрам и с очень хорошим отрывом.

                      • 9. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                        AntonVZhbankov Guru

                        >Причина - размер кластера в VMFS5 = 1 MB

                         

                        Ну вот не совсем так. Нет большого влияния размера блока VMFS на дисковый ввод-вывод кроме случаев роста виртуальных дисков и создания ВМ.

                        Я бы даже сказал, что вообще никакой свзяи между размером дисковой операции и блоком VMFS нет.

                        • 10. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                          AntonVZhbankov Guru

                          >И по скорости, даже 5-й рэйд на SAS 10k уделывает 10-ку на SATA. причем уделывает по всем параметрам и с очень хорошим отрывом.


                          SATA - 90 IOPS
                          SAS 10k - 130 IOPS.

                           

                          Из одного и того же количества дисков получаем:

                          10 дисков, 70/30 R/W - 566 IOPS SATA / 666 SAS

                          10 дисков, 30/70 R/W - 433 IOPS SATA /  408 SAS

                           

                          Вывод - не всегда, зависит от нагрузки. При равном количестве дисков 10ка даже из SATA может делать 5ку из 10k, если в нагрузке преобладает запись.

                          • 11. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                            AntonVZhbankov Guru

                            >Значит вы рекомендуете использовать все 8 дисков под 10 raid без хотспары?

                             

                            Замерьте вашу нагрузку, если там мало записи, то я бы советовал RAID 6 и обязательно положить в ящик запасной диск, если не два. Если записи много - 10ка.

                            • 12. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                              AntonVZhbankov Guru

                              >При использовании VMFS все команды от гостя перехватываются. интерпритируются кернелом под формат гипервизора и потом уже передаются на VMFS.

                               

                              Откуда дровишки?

                              • 13. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                                Sladky Master

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

                                 

                                1. Теория IOPS - это хорошо, но на практике не всё так гладко. Начнем с того, что у SAS в 3 раза меньше задержки (примерно 3 против 9). Потом, у SATA длина очереди 32 против 256 у SAS. Уж не знаю как там с теорией, но на практике RAID5 SAS 10к  и RAID10 SATA 7.2к из примерно одинакового количества дисков работают ну с очень разной скоростью. И по пропускной способности и и особенно по латентности. Естественно, ВМ на этих датасторах ведут себя совершенно по разному.

                                При работе в 1 поток с дисковой подсистемой (думаю, процент таких приложений устрашает) всё упирается в её латентность. Пример: у нас гипотетическая хранилка на SATA, выдающая 5 миллионов IOPS (пусть такм миллион дисков будет),  противопоставляем ей хранилку на SAS, которая выдаёт 1000 тех же самых IOPS. И вот у нас приложение пытается в 1 поток писать (или читать) с такой хранилки SATA. Задержка пусть будет 9ms. 1000/9=111 IOPS. Это тот максимум, который получит приложение. Что же у нас с SAS? При задержке в 3ms приложение получит уже 333 IOPS. И больше, и более отзывчиво. Так что не все йопсы одинаково полезны, как говорится. Их еще и реально получить как-то надо, а вот с этим возникают проблемы.

                                Ну, и открою всем очевидную тайну (вроде она на поверхности, но озвучивается редко). Все уровни RAID на чтение имеют практически идентичные IOPS. А вот запись сильно отличается. В принципе, Антон уже коснулся этого тезиса чуть выше.

                                2. Про дровишки. Уж вам ли не знать принцип работы гипервизора ESXi? ВМ работает с тем типом контроллера, который установлен для неё в виртуальном железе. И прослоек с различными виртуализациями систем хранения там как минимум  4 штуки, а может быть и более. Последними слоями занимается RAID контроллер и мозги самих дисков, а вот первые разгребает госевая ОС и гипервизор. ОС работет с диском, подозревая что это некий скази и шлёт ему соответствующие команды. В этом момент гипервизор снимает машину с физических ядер и отправляет в очередь WAIT, подделывая при этом запросы ВМ в необходимый гипервизору вид для общения с системой хранения (это может быть что угодно, iSCSI, FC, SAS, SATA и т.д.) Так что команды внутри ОС гостя и команды общения гипервизора с системой хранения - это действительно 3 большие разницы.

                                 

                                Кстати, раз уж тема зашла про IOPS, давайте я всем мозг взорву. На IOPS ВМ влияет не только тип и производительность системы хранения, но и процессы, происходящие внутри ВМ. А точнее параллельные обращения ВМ к вводу-выводу, а так же текущая нагрузка на процессоры хоста. Всё сказанное достоверно на 100% для iSCSI, но по видимому и для FC тоже актуально (надо проверять).

                                 

                                Итак, тестовый стенд:

                                2хXeon E5 2690

                                394 GB RAM

                                2x10 Gbit LAN Intel X540 T2

                                 

                                Хранилка 2xXeon 2609 + 192 GB RAM + Starwind 6 + Ramdrive 100GB + iSCSI 10 Gbit

                                Свитч Dell 8024 10 Gbit

                                 

                                Измеряем IOPS при помощи IOMETER, 100% случайное чтение в 1 поток блоками по 4к

                                 

                                Итак, физическая машина, будучи подключенной к этой системе хранения снимает 90к+ IOPS в один поток.

                                 

                                Измеряем из ВМ, (2 vCPU), получаем 4000 IOPS в 1 поток (в 256 потоков 90к IOPS тоже снимаются)

                                При этом нагрузка на процессоры хоста практически 0

                                По показателмя esxtop GAVG=DAVG= 0.22ms

                                 

                                Теперь нагружаем другими ВМ процессоры хоста до 80%.

                                Измеряем из ВМ,  получаем 1900 IOPS в 1 поток!!!

                                esxtop GAVG=DAVG= 0.4ms (как так? у нас система хранения виновата? Да ну?)

                                 

                                Убираем нагрузку с процов хоста, тестовая ВМ опять одна.

                                Но пробуем работать с сетью (у хоста 2 сетевых адаптера, один выделен под iSCSI, воторой под работу с сетью)

                                Копируем из сети большой файл и кладём его на диск ВМ (другой диск, не тот, который меряется на IOPS, он физически лежит на другой системе хранения)

                                Измеряем из ВМ,  получаем 2000 IOPS в 1 поток!!!

                                esxtop GAVG=DAVG= 0.32ms (опять?)

                                 

                                Ну и для верности

                                Пробуем работать с чистой сетью

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

                                Измеряем из ВМ,  получаем 3000 IOPS в 1 поток!!!

                                esxtop GAVG=DAVG= 0.31ms (и снова?)

                                 

                                Вот такие вот интересные показатели. Так что теория IOPS у систем хранения и практика VMWare не совсем равны. Продолжаю наблюдения...

                                 

                                P.S. ИМХО, во всём виноваты постановки ВМ в очередь WAIT при работе с вводом-выводом. Больше ничем не могу объяснить такую картину. Ответ ищу уже давно, но все молчат, в том числе гугл и специалисты VMWare. Может вы чего подскажете?

                                Ну, и просил коллег на других системах померить максимальные IOPS в 1 поток. Тоже упёрлись в 4000. Магическое число... И на Hyper-V тоже в 4000 упёрлись. Хранилки использовались правильные 2-головые, тоже на iSCSI 10 Gbit. Диски SSD.

                                Кстати, смотрел документацию на свитч Dell, который использовался в тесте. Так вот, он по идее даёт задержки в районе 3-4 микросекунд (0.003-0.004ms). Вероятно, оно тоже виновато.

                                 

                                P.P.S. К чему я это всё? А к тому, что если у вас машина интенсивно работает с вводом-выводом, и не дай Бог еще и параллельно с диском и сетью - то тормозить она будет качественно Как вариант, сервер баз данных Но надо признать, что VMWare прямо не рекомендует виртуализовывать сервисы, имеющие гиперактивный ввод-вывод.

                                 

                                Последние тесты показали, что в беде с 4000 IOPS по сути виновата сеть, скорее всего.

                                Если подключить физическую машину через свитч, то у неё тоже IOPS в 1 поток упираются в 4000. Продолжаю наблюдения...

                                 

                                Message was edited by: Oleg Solodky

                                • 14. Re: Какой размер кластера выбрть для ESXi 5.1 при построении RAID
                                  AntonVZhbankov Guru

                                  Олег, не надо сравнивать теплое с мягким.
                                  А именно бытовые SATA диски с SAS дисками. Говоря о сравнении SATA/SAS в RAID в системах хранения, например, имеют в виду и те и другие диски корпоративного класса. С подключением по двум портам.
                                  А с недавнего времени вместо SATA и FC дисков в системах EMC VNX используются только SAS диски. Только экс-SATA сейчас называются NL-SAS диски.Но надо признать, что VMWare прямо не рекомендует виртуализовывать сервисы, имеющие гиперактивный ввод-вывод.

                                   

                                  Говоря о Starwind вообще непонятно кого с кем сравниваем.

                                   

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

                                   

                                  >Но надо признать, что VMWare прямо не рекомендует виртуализовывать сервисы, имеющие гиперактивный ввод-вывод.

                                   

                                  Вот неправда. Именно для них сделана куча изменений и придуман pvscsi.

                                  1 2 Previous Next