Этот труднопереводимый термин предполагает следующую ситуацию:
У вас есть несколько относительно-медленных потребителей и ограниченное число портов на коммутаторе.
Логично, что вы решаете повесить их на один порт с помощью последовательного соединения, вроде того же каскада. В качестве вариации на тему: подключение нескольких клиентов с каналами 8 Гб к отдельным портам коммутатора; а сам коммутатор подключен к сети с хранилищами недостаточно быстрым линком.
Если скорость порта, к которому подключены все эти устройства, не позволяет одновременно обслужить всех без проседания скорости, то с высокой вероятностью у вас будут проблемы. Закон Мерфи никто не отменял.
Это немного узкий взгляд на термин. И даже неожиданный, я бы сказал.
Изначально под ним имеется ввиду соотношение N-портов (конечных устройств) инициаторов к E-портам (ISL) и таргетам. То есть если мы подключим к одному свичу 10 инициаторов на 10 портов и таргет на 1 порт, получим переподписку 10:1. Если же мы таргет подключим к двум портам, то уже 5:1.
Если на пальцах совсем.
Вендорами рекомендуется не больше 6-7:1
Возможность построения территориально распределенной SAN;
Минимальная латентность;
Высокая скорость передачи данных;
Возможность репликации и создания снапшотов силами дискового массива.
Не понял, куда всё это делось у iSCSI и FCoE? И почему не указана такая особенность, как Flow control? Или это плюсы по сравнению с SAS только?
А почему iSCSI ограничен 10 гигабитами, а то время как для FC заявлены современные 128? Я отстал немного от темы, но мне кажется 40 Гб/с уже давно доступны для ethernet.
В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).
Что-то представление кольца из одного коммутатора вызывает у меня короткое замыкание. В целом немного противоестественная картина — FC выбирают, когда нужна не только скорость, но и надёжность, а это минимум 2 фабрики, т.е. 2 свича.
В целом по статье, сведения безусловно полезные, но, боюсь, если бы я не владел уже описанной в ней информацией, я бы мало что понял. Уж больно фрагментарно и намешано в кучу коней и людей.
Cнижает доступность при установке патчей Windows, т.е. хост надо перезагружать не только при установке патчей гипервизора, но и ОС.
Но ведь если вам от хостовой ОС нужен только функционал гипервизора, то вы используете не Windows Server Full Mode, а Hyper-V Server, что нивелирует разницу.
если новые функции виртуализации Hyper-V будут реализованы только после выхода «не относящегося к виртуализации функционала», то с точки зрения виртуализации это недостаток.
Разве что для экстремалов, разворачивающих в продуктив новые версии сразу после выпуска. Остальным доступны Technical preview для ознакомления как раз с уже реализованными новыми функциями.
К слову, несмотря на этот недостаток, динамика развития функционала в Hyper-V пока существенно выше, чем в vSphere. Одна виртуализация сети чего стоит.
Какой сложносоставной маркетинговый пресс-релиз получился. «VMware лучше всех, потому что популярнее и вообще..., а мы выбрали VMware, поэтому мы лучшие»
но главным недостатком архитектуры Hyper-V по-прежнему остаётся использование родительской ОС, что снижает безопасность и доступность гипервизора при установке патчей и обслуживании материнской Windows Server.
Я не понял, как использование родительской ОС снижает безопасность при установке патчей? Если речь про лишние сервисы и компоненты, кто мешает юзать Hyper-V? Если о доступности — разве при установке патчей на esxi не требуется перезагружать хост?
Кроме того, зависимость от Windows Server означает, что реализация в Hyper-V новых функций виртуализации происходит только при выходе новых версий этой ОС.
А в vSphere все новые функции распространяются на старые версии? Или версии сферы выходят сильно чаще? Или наличие не относящегося к виртуализации функционала считается недостатком?
Однако Failover clustering не оптимизирована для защиты ВМ.
А в чём это выражается? Притом, что именно для защиты ВМ в Win2012 появились отдельные изменения функционала Failover Clustering.
Для возникновения вопросов нужно чтобы было за что зацепиться. Это когда в целом посыл ясен, но есть туманности и неопределённости.
Посыл данной статьи: «Есть такая штука — DRS — она крутая, реализует балансировку нагрузки, и мы её используем». И никаких вопросов не возникает, потому что в статье просто нет того, что обещает заголовок.
Если стремитесь развиваться, стоит менее остро реагировать на замечания и больше задумываться о причинах, их вызвавших.
«Подскажите, как правильно» — не тот настрой, который способствует саморазвитию.
Это наверное полезная статья, так что минусовать рука не поднимается, но что она делает в хабе «виртуализация»? Просто из-за наличия докера в процессе подготовки? Эдак можно добавлять сюда что угодно, просто по факту того, что что угодно можно запускать в виртуальной среде.
Я просто интересуюсь технологиями виртуализации, но не интересуюсь веб-программировании и уже не знаю как мне отфильтровать ленту, чтобы не видеть статьи о веб-разработке от людей, открывших для себя VMware Workstation.
Тоже верно.
Главное чтоб ВМ в хостах были схожей конфигурации и со схожей нагрузкой. Иначе очень мало получается «общих страниц». По сути, только пустые.
Как показал опыт, TPS имеет смысл использовать только на VDI и только при нехватке памяти. Нагрузка на процессор получается заметная.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.
Да, именно потому вытащили из SVC все датасторы (и остальное планируем).
В нашем случае это из-за того, что почему-то версия прошивки svc не совместима с ATS из VAAI, а также из-за того, что «интеллектаульность» svc ниже размещённых за ней стораджей (emc).
Убрали всё лишнее с VNX, размазали датасторы по всему объёму — теперь много неиспользованного места, но и latency ниже.
Стандартные 4 (с 22:00 по 2 часа) окна обслуживания для установки обновлений пришлось ещё раскромсать до 8 — теперь второе окно стартует через час после первого, а не дожидаясь окончания, поскольку пик по IOPS приходится на первые пол часа, а потом линейно падает.
Добавили памяти ВМ — уменьшился свопинг.
Настроили BITS, чтоб обновления тянулись в течение рабочего дня, но медленно (4 кб/с).
Долго и вдумчиво настраивали касперского и его обновления.
У нас в VDI-ферме это особенно заметно. Даже агент SCCM прикладывал VNX до потери датасторов.
Жаль, что Касперский сделал эту фичу только в серверных версиях.
Предполагается, что люди не работают в консоли сервера, в основном.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.
Влияет опосредованно. Если vCenter в коме, менеджмент затруднён, а значит в случае перепадов и скачков нагрузки, DRS не сможет своевременно перебалансировать кластер. Да и вообще оценить, что надо перебалансировать, потому что статистика будет собираться местами и не вся.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.
Это немного узкий взгляд на термин. И даже неожиданный, я бы сказал.
Изначально под ним имеется ввиду соотношение N-портов (конечных устройств) инициаторов к E-портам (ISL) и таргетам. То есть если мы подключим к одному свичу 10 инициаторов на 10 портов и таргет на 1 порт, получим переподписку 10:1. Если же мы таргет подключим к двум портам, то уже 5:1.
Если на пальцах совсем.
Вендорами рекомендуется не больше 6-7:1
Не понял, куда всё это делось у iSCSI и FCoE? И почему не указана такая особенность, как Flow control? Или это плюсы по сравнению с SAS только?
А почему iSCSI ограничен 10 гигабитами, а то время как для FC заявлены современные 128? Я отстал немного от темы, но мне кажется 40 Гб/с уже давно доступны для ethernet.
Что-то представление кольца из одного коммутатора вызывает у меня короткое замыкание. В целом немного противоестественная картина — FC выбирают, когда нужна не только скорость, но и надёжность, а это минимум 2 фабрики, т.е. 2 свича.
В целом по статье, сведения безусловно полезные, но, боюсь, если бы я не владел уже описанной в ней информацией, я бы мало что понял. Уж больно фрагментарно и намешано в кучу коней и людей.
Но ведь если вам от хостовой ОС нужен только функционал гипервизора, то вы используете не Windows Server Full Mode, а Hyper-V Server, что нивелирует разницу.
Разве что для экстремалов, разворачивающих в продуктив новые версии сразу после выпуска. Остальным доступны Technical preview для ознакомления как раз с уже реализованными новыми функциями.
К слову, несмотря на этот недостаток, динамика развития функционала в Hyper-V пока существенно выше, чем в vSphere. Одна виртуализация сети чего стоит.
Я не понял, как использование родительской ОС снижает безопасность при установке патчей? Если речь про лишние сервисы и компоненты, кто мешает юзать Hyper-V? Если о доступности — разве при установке патчей на esxi не требуется перезагружать хост?
А в vSphere все новые функции распространяются на старые версии? Или версии сферы выходят сильно чаще? Или наличие не относящегося к виртуализации функционала считается недостатком?
А в чём это выражается? Притом, что именно для защиты ВМ в Win2012 появились отдельные изменения функционала Failover Clustering.
Посыл данной статьи: «Есть такая штука — DRS — она крутая, реализует балансировку нагрузки, и мы её используем». И никаких вопросов не возникает, потому что в статье просто нет того, что обещает заголовок.
Я начинаю стесняться заходить на хабр.
«Подскажите, как правильно» — не тот настрой, который способствует саморазвитию.
Я просто интересуюсь технологиями виртуализации, но не интересуюсь веб-программировании и уже не знаю как мне отфильтровать ленту, чтобы не видеть статьи о веб-разработке от людей, открывших для себя VMware Workstation.
Главное чтоб ВМ в хостах были схожей конфигурации и со схожей нагрузкой. Иначе очень мало получается «общих страниц». По сути, только пустые.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.
Ну или четвёртый хост в качестве iSCSI-таргета :)
В нашем случае это из-за того, что почему-то версия прошивки svc не совместима с ATS из VAAI, а также из-за того, что «интеллектаульность» svc ниже размещённых за ней стораджей (emc).
Чёрт, я забыл про SIOC в статье…
Жаль, что Касперский сделал эту фичу только в серверных версиях.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.