Не увидел самого главного в этом аппарате. Где контроль температуры паров, поступающих в холодильник?
Ведь весь смысл разделения жидкостей в данном случае с точки зрения физхимии построен на разности температур кипения этих жидкостей в смеси. В частности температура кипения спирта при атмосферном давлении, если мне память не изменяет, составляет 80 градусов Цельсия. Жидкости в смеси закипают строго по очереди (если использовать медленный нагрев, а не разводить костер под емкостью), как только закипает жидкость с наименьшей температурой кипения, рост температуры пара над общей смесью останавливается. И пока вся эта лекгокипящая жидкость из смеси не испарится, температура не будет расти. Соответственно спирт имеет смысл отбирать когда градусник останавливается на температуре близкой к 80 градусам. В разных регионах плюс минус 1-2 градуса может быть (от положения к уровню моря зависит). На Урале например спирт спокойно кипит при 79 градусах. Но температура абсолютно точно застопорится на одном значении. А дальше как только температура резко пошла вверх, нужно прекращать отбор спирта.
А простите, вы первый мой комментарий читали? Или проигнорировали?
А если взять в работу ваше последнее утверждение, то СХД должна просто состоять из кэша в оперативной памяти и видимо CPU. А это почему-то все еще не так, хотя к этому постепенно идет. А значит service time диска в принципе по физическим причинам не может равняться response time на сервере, где работает приложение, так то SAN тоже ни куда пока не делась со всеми ее компонентами. Но вы можете и дальше продолжать заново изобретать теорию построения своего велосипеда, игнорируя давно придуманное и устоявшееся. Прежде чем о чем-то спорить вы хотя бы с основами, теорией и устоявшейся в отрасли терминологией разберитесь.
Интересный опыт. Но не совсем понятно как именно peer zoning повлиял на выравнивание нагрузки на директора VPLEX. Не пробовали с этим разобраться? В плане найти логическое объяснение. Просто по описанию из статьи формально для серверов и HBA в них ничего не изменилось.
В описании стенда в статье не увидел попытки проанализировать, во что именно "утыкался" тест на гипервизорах. Что касается VMware и дисковых операций, то не вижу что настраивали это и вот это. Что касается производительности MPIO VMware при Round-Robin нужно настраивать это. На старых HBA Qlogic в биосе под виртуализацией еще нужно выкручивать на максимум параметр "Execution Throttle" в "Advanced Adapter Settings".
Опять же указанные в стенде Dell Compellent SC200 — это вроде как SAS полки расширения. А судя по описанию стенда, сервер у вас к СХД цеплялся по FC. Т.е. что за СХД не понятно. Ну и зная компеленты, их надо еще и уметь правильно готовить. Накосячить там можно крайне легко на любом этапе, начиная прямо с составления спецификации на СХД.
Еще раз, без уточнения что за виртуализация и как именно она настроена, все выше сказанное ни о чем не говорит. Понятно, что гипервизор — это дополнительная прослойка. Но это не отменяет того, что и как любой софт она поддается тюнингу. А значит без уточнения конфигурации стенда и его настроек это всего лишь ваш личный опыт, из которого нельзя делать общие выводы. Вы хотя бы попытались понять, в каком месте возникает узкое место? CPU? DIMM? Дисковые очереди? Что-то еще?
По поводу 5 мелкософт тут пишет, что выключить IPv6 можно.
Я к 1С отношения не имею, но меня улыбают ваши отсылки к Гилеву, который у себя на сайте утверждает, что CrystalMark — это хороший тест для экспресс оценки дисковой подсистемы. Хотя на самом деле CristalMark годится разве что USB флешки тестировать. То же самое и с вашими/Гилева утверждениями по виртуализации. Во первых не вся виртуализация одинакова, во вторых, как и везде виртуализацию нужно уметь правильно готовить. 15-25% потери производительности больше похоже на страшилку для начинающих детей.
С другой стороныя понимаю, что нельзя быть специалистом во всем. Так что-то вполне хороший спец в 1С может при этом иметь очень поверхностные знания в серверах, сетях хранения, СХД, операционных системах и виртуализации. Главное что бы он сам это осознавал и не порол горячку типа "у меня не получилось, значит и ни у кого не получится". :)
А у вас везде всё строго задублировано, кластеризовано и вендор готов в три часа доставить запчасть со склада?
На работе именно так :). Правда с 3 часами на доставку запчасти это перебор, если вы конечно не в Москве и готовы платить за эту оперативность. NBD вполне достаточно.
Что касается домашней инфраструктурки, то тут все в меру возможностей и здравого смысла.
Лицензии для постоянного использования вложенных гипервизоров нужны. А вот на сделать лабу и поиграться я думаю дефолтного двухмесячного триала должно быть достаточно.
Ну и согласен, что погорячился. Но тем не менее оффициально не поддерживается и не работает — это не одно и то же. https://www.vmgu.ru/news/vmware-nested-esxi-content-library
Где памяти-то столько взять на домашнем сервере? И дискового пространства под винду Hyper-V? :)
А про ESXi не сомневайтесь :). Вложенная виртуализация давно поддерживается.
Вот тут нужно опять же разделить мух и котлеты. Я не имею ничего принципиально против управляемых коммутаторов :). Но если по теме статьи, цель автора, как я его понял, была собрать стенд для экспериментов. И в данном случае чем проще и дешевле, тем лучше. Можно для третьего сервера и еще одну сетевую карту воткнуть. И с неуправляемым коммутатором я тут особых проблем не вижу. Ну будет с его точки зрения подключено какое-то количество неизвестных ему устройств, каждое из которых имеет свой mac и IP. Ну обмениваются они по TCP/IP какими-то пакетами. С какого IP и физ.интерфейса слать следующий пакет решается на стороне multipath I/O на сервере.
Если же говорить о нормальном продуктиве, то не думаю, что кто-то в здравом уме решиться использовать FreeNAS под хранения виртуалок, т.к. точкой отказа тут сразу будет сам сервер/компьютер, на котором это поднято. Если использовать для сети хранения данных iSCSI, то опять же для отказоустойчивости нужны будут минимум две отдельных физических фабрики. Каждая из которых состоит как минимум из одного коммутатора. В идеале в этих фабриках не должен бегать трафик пользователей (от серверов к клиентам), а значит VLAN не понадобятся.
Почему отдельные коммутаторы и две фабрики под iSCSI? Причин может быть несколько. Начиная от упрощения конфигурирования, обслуживания и замены неисправных до улучшения общей производительности, за счет отсутствия пользовательского трафика. Наиболее простой пример, если накосячить с изменением конфигурации и прервать доступ пользователей к серверам, то будет не приятно, но не смертельно. А вот если на ходу случайно у гипервизора оторвать датастор с виртуалками, то есть не нулевая вероятность, что не все виртуальные машины и сервисы на них смогут пережить такое отношение.
Вы немного путаете теплое с мягким. MPIO разруливается на стороне OS сервера. В данном случае гипервизора. И коммутаторы тут как бы остаются не при чем. Правда и сетевую карту лучше иметь с поддержкой iSCSI инициаторов, а не использовать софтовый.
И что касается тиминга и агрегации, то в случае iSCSI они скорее вредны, чем полезны. Так как MPIO гарантированно равномерно разложит нагрузку по всем активным физическим путям, в отличии от агрегированных интерфейсов.
Не увидел самого главного в этом аппарате. Где контроль температуры паров, поступающих в холодильник?
Ведь весь смысл разделения жидкостей в данном случае с точки зрения физхимии построен на разности температур кипения этих жидкостей в смеси. В частности температура кипения спирта при атмосферном давлении, если мне память не изменяет, составляет 80 градусов Цельсия. Жидкости в смеси закипают строго по очереди (если использовать медленный нагрев, а не разводить костер под емкостью), как только закипает жидкость с наименьшей температурой кипения, рост температуры пара над общей смесью останавливается. И пока вся эта лекгокипящая жидкость из смеси не испарится, температура не будет расти. Соответственно спирт имеет смысл отбирать когда градусник останавливается на температуре близкой к 80 градусам. В разных регионах плюс минус 1-2 градуса может быть (от положения к уровню моря зависит). На Урале например спирт спокойно кипит при 79 градусах. Но температура абсолютно точно застопорится на одном значении. А дальше как только температура резко пошла вверх, нужно прекращать отбор спирта.
А за саму автоматизацию зачет :).
Хост получает ack после того как блок отреплицировался на соседнюю ноду? Или сразу после записи блока на первую ноду?
А простите, вы первый мой комментарий читали? Или проигнорировали?
А если взять в работу ваше последнее утверждение, то СХД должна просто состоять из кэша в оперативной памяти и видимо CPU. А это почему-то все еще не так, хотя к этому постепенно идет. А значит service time диска в принципе по физическим причинам не может равняться response time на сервере, где работает приложение, так то SAN тоже ни куда пока не делась со всеми ее компонентами. Но вы можете и дальше продолжать заново изобретать теорию построения своего велосипеда, игнорируя давно придуманное и устоявшееся. Прежде чем о чем-то спорить вы хотя бы с основами, теорией и устоявшейся в отрасли терминологией разберитесь.
Ну судя по тому что контраргуменов у вас не возникло, то ваше последнее утверждение близко к истине.
Вот так уже понятнее. А то из самой статьи создается впечатление некой магии при применении Peer Zoning :).
Кстати, а на backend-е VPLEX до СХД какой тип зонинга используется?
Интересный опыт. Но не совсем понятно как именно peer zoning повлиял на выравнивание нагрузки на директора VPLEX. Не пробовали с этим разобраться? В плане найти логическое объяснение. Просто по описанию из статьи формально для серверов и HBA в них ничего не изменилось.
Вам спасибо за отзыв.
В описании стенда в статье не увидел попытки проанализировать, во что именно "утыкался" тест на гипервизорах. Что касается VMware и дисковых операций, то не вижу что настраивали это и вот это. Что касается производительности MPIO VMware при Round-Robin нужно настраивать это. На старых HBA Qlogic в биосе под виртуализацией еще нужно выкручивать на максимум параметр "Execution Throttle" в "Advanced Adapter Settings".
Опять же указанные в стенде Dell Compellent SC200 — это вроде как SAS полки расширения. А судя по описанию стенда, сервер у вас к СХД цеплялся по FC. Т.е. что за СХД не понятно. Ну и зная компеленты, их надо еще и уметь правильно готовить. Накосячить там можно крайне легко на любом этапе, начиная прямо с составления спецификации на СХД.
Еще раз, без уточнения что за виртуализация и как именно она настроена, все выше сказанное ни о чем не говорит. Понятно, что гипервизор — это дополнительная прослойка. Но это не отменяет того, что и как любой софт она поддается тюнингу. А значит без уточнения конфигурации стенда и его настроек это всего лишь ваш личный опыт, из которого нельзя делать общие выводы. Вы хотя бы попытались понять, в каком месте возникает узкое место? CPU? DIMM? Дисковые очереди? Что-то еще?
Может у конкурентов просто ЧСВ не так развито? Хотя про это не мне судить. Я с миром 1С практически не пересекаюсь.
По поводу 5 мелкософт тут пишет, что выключить IPv6 можно.
Я к 1С отношения не имею, но меня улыбают ваши отсылки к Гилеву, который у себя на сайте утверждает, что CrystalMark — это хороший тест для экспресс оценки дисковой подсистемы. Хотя на самом деле CristalMark годится разве что USB флешки тестировать. То же самое и с вашими/Гилева утверждениями по виртуализации. Во первых не вся виртуализация одинакова, во вторых, как и везде виртуализацию нужно уметь правильно готовить. 15-25% потери производительности больше похоже на страшилку для
начинающихдетей.С другой стороныя понимаю, что нельзя быть специалистом во всем. Так что-то вполне хороший спец в 1С может при этом иметь очень поверхностные знания в серверах, сетях хранения, СХД, операционных системах и виртуализации. Главное что бы он сам это осознавал и не порол горячку типа "у меня не получилось, значит и ни у кого не получится". :)
На работе именно так :). Правда с 3 часами на доставку запчасти это перебор, если вы конечно не в Москве и готовы платить за эту оперативность. NBD вполне достаточно.
Что касается домашней инфраструктурки, то тут все в меру возможностей и здравого смысла.
Ну и вот тут.
Лицензии для постоянного использования вложенных гипервизоров нужны. А вот на сделать лабу и поиграться я думаю дефолтного двухмесячного триала должно быть достаточно.
Ну и согласен, что погорячился. Но тем не менее оффициально не поддерживается и не работает — это не одно и то же.
https://www.vmgu.ru/news/vmware-nested-esxi-content-library
Где памяти-то столько взять на домашнем сервере? И дискового пространства под
виндуHyper-V? :)А про ESXi не сомневайтесь :). Вложенная виртуализация давно поддерживается.
Я просто пытался расширить ваш кругозор, простите глупого :).
Все ухожу дальше кроваво энтерпрайзить… :)
Ну и почитав вот тут: https://serveradmin.ru/ustanovka-i-nastroyka-windows-hyper-v-server-2016/ не назвал бы установку и настройку Hyper-V абсолютно интуитивно понятной и простой :). В ESXi настройка сводиться практически к прохождению одного простого визарда и ожиданию окончания установки.
И это на одном физическом сервере? :)
Вот тут нужно опять же разделить мух и котлеты. Я не имею ничего принципиально против управляемых коммутаторов :). Но если по теме статьи, цель автора, как я его понял, была собрать стенд для экспериментов. И в данном случае чем проще и дешевле, тем лучше. Можно для третьего сервера и еще одну сетевую карту воткнуть. И с неуправляемым коммутатором я тут особых проблем не вижу. Ну будет с его точки зрения подключено какое-то количество неизвестных ему устройств, каждое из которых имеет свой mac и IP. Ну обмениваются они по TCP/IP какими-то пакетами. С какого IP и физ.интерфейса слать следующий пакет решается на стороне multipath I/O на сервере.
Если же говорить о нормальном продуктиве, то не думаю, что кто-то в здравом уме решиться использовать FreeNAS под хранения виртуалок, т.к. точкой отказа тут сразу будет сам сервер/компьютер, на котором это поднято. Если использовать для сети хранения данных iSCSI, то опять же для отказоустойчивости нужны будут минимум две отдельных физических фабрики. Каждая из которых состоит как минимум из одного коммутатора. В идеале в этих фабриках не должен бегать трафик пользователей (от серверов к клиентам), а значит VLAN не понадобятся.
Почему отдельные коммутаторы и две фабрики под iSCSI? Причин может быть несколько. Начиная от упрощения конфигурирования, обслуживания и замены неисправных до улучшения общей производительности, за счет отсутствия пользовательского трафика. Наиболее простой пример, если накосячить с изменением конфигурации и прервать доступ пользователей к серверам, то будет не приятно, но не смертельно. А вот если на ходу случайно у гипервизора оторвать датастор с виртуалками, то есть не нулевая вероятность, что не все виртуальные машины и сервисы на них смогут пережить такое отношение.
Вы немного путаете теплое с мягким. MPIO разруливается на стороне OS сервера. В данном случае гипервизора. И коммутаторы тут как бы остаются не при чем. Правда и сетевую карту лучше иметь с поддержкой iSCSI инициаторов, а не использовать софтовый.
И что касается тиминга и агрегации, то в случае iSCSI они скорее вредны, чем полезны. Так как MPIO гарантированно равномерно разложит нагрузку по всем активным физическим путям, в отличии от агрегированных интерфейсов.