Опять-таки есть ряд нюансов, из-за которых картина выглядит не столь пугающей, как Вы обрисовали ))
1. Если говорить о гипервизорах VMware, то все работы по установке обновлений/патчей можно производить последовательно, на каждом отдельном сервере, передвигая ВМ на другие сервера с помощью vMotion (благо для таких операций есть всегда резервные сервера). Если все-таки потребуется перезапуск ВМ для каких-то обновлений, то да, в этом случае у пользователя будет небольшой перерыв в работе его сервиса (например, интернет-магазина).
2. Тестирование после установки обновления/патча не занимает много времени, и уж тем более не выльется в ситуацию «всё облако месяц лежать будет» :)
В целом Ваши опасения понятны, радикальное решение этой проблем, как отметил nickolazz, это использование облака с географически распределенным кластером на нескольких площадках. Это собственно предлагается в рамках CloudLine.
Не совсем так: в пункте 4.1.2. речь идет об обновлениях и патчах, имеющих критическое значение для работоспособности, производительности, безопасности ОС.
Уведомление рассылается в обязательном порядке всем клиентам (на email, указанный при регистрации) непосредственно перед работам с указанием примерного времени работ. Об этом также написано в этом пункте.
Если речь идет о компенсации, то за нарушение SLA мы начисляем бесплатное время пользования сервисом.
Фиксация нарушений SLA будет проходить на основании нашей системы мониторинга и обращений клиента на support@cloudlite.ru.
У Амазона есть нечто подобное: если есть простаивающие ресурсы, то провайдер выставляет их на аукцион, в котором пользователи
сами назначают цену одного часа аренды ресурсов. Победитель получает незадействованные ресурсы по его цене. Однако как только на ресурсы снова появится спрос или ставка будет перебита, то эти ресурсы больше не ваши. Как-то так.
Методы построения DCI, пожалуй, тема для отдельного поста.
В этой публикации мы рассмотрели методы борьбы с петлями, испытанные нами на практике.
Построение Ethernet фабрик (мы используем FabricPath) — один из способов борьбы с петлями и один из приемлемых вариантов соединения ЦОД по L2 без угроз возникновения закольцованностей (проверено в боевых условиях).
VCS и Qfabric упомянуты как альтернативы FP, и мы не ставили цели перечислять все существующие технологии.
Это зависит от типа коммутатора и шторма. По нашему горькому опыту на Layer 3 коммутаторах CPU грузит процесс ARP input, т. е. на CPU летят ARP пакеты.
Именно на фоне всплеска трафика на L2 коммутаторах CPU может грузить и MAC-learning.
Действительно, от этой проблемы нет волшебной пилюли. Проблема комплексная и подход к её решению должен быть комплексным. Сложно полностью исключить возможность возникновения петель, но свести к минимуму этот риск и последствия широковещательных штормов очень даже реально.
В вашем примере с серверами при правильной настройке портов коммутатора можно смягчить последствия шторма, применив storm-control и ограничив количество обрабатываемых пакетов процессором с помощью инструмента CoPP.
Также можно настроить на порту Layer 2 ACL, разрешив трафик только с MAC-адреса этого сервера.
1. Да, вы правы, Qfabric не является протоколом, это проприетарная технология от Juniper.
В статье хотели показать, что Qfabric является вариантом TRILL в отношении формирования единой фабрики без угрозы возникновения петель коммутации внутри этой фабрики. Спасибо за уточнение, поправили этот момент в тексте и еще добавили VCS от Brocade.
2. Для того, чтобы избежать флуда на соседний ЦОД, необходимо разграничение на L3 (по маршрутизации), например, организовать связь между ЦОД через L3VPN. Для нас этот вариант не подходит, т.к. между ЦОД требуется растянутый L2 сегмент для работы vMotion.
Мы выбрали FabricPath, протокол достаточно надежен и прост в эксплуатации (легко настраивается, достаточно быстро можно добавлять новые VLAN). За 2 года эксплуатации ни разу не подвел.
При необходимости подключения в схему третьего ЦОД, можно будет рассмотреть возможность перехода на OTV + FabricPath.
Да, здесь допущена неточность в формулировке. Широковещательный шторм как правило сопровождается ростом количества пакетов в сети (multicast, broadcast, unknown unicast). Поправили. Спасибо)
Конечно же, мы отделяем клиентский L2-сегмент от своей сетевой инфраструктуры VLAN’ми, но при шторме в клиентской сети шторм воздействовал и на CPU наших коммутаторов доступа. Это привело к «развалу» наших внутренних STP процессов и в конечном итоге вызвало шторм во всех остальных VLAN. Рекомендации, приведенные в конце статьи, помогут предотвратить подобные ситуации)
Мы используем и SDMO, и FG Wilson (на видео он кстати тоже есть — в контейнерном исполнении).
Температурный режим в помещении аккумуляторной, так же как и в других технологических помещениях, поддерживается в необходимых рамках и постоянно мониторится.
Мертвый АКБ в группе определяется автоматическими тестированиями, которые проводят сами ИБП, и дополнительными тестированиями, которые проводятся в рамках ТО.
1. Если говорить о гипервизорах VMware, то все работы по установке обновлений/патчей можно производить последовательно, на каждом отдельном сервере, передвигая ВМ на другие сервера с помощью vMotion (благо для таких операций есть всегда резервные сервера). Если все-таки потребуется перезапуск ВМ для каких-то обновлений, то да, в этом случае у пользователя будет небольшой перерыв в работе его сервиса (например, интернет-магазина).
2. Тестирование после установки обновления/патча не занимает много времени, и уж тем более не выльется в ситуацию «всё облако месяц лежать будет» :)
В целом Ваши опасения понятны, радикальное решение этой проблем, как отметил nickolazz, это использование облака с географически распределенным кластером на нескольких площадках. Это собственно предлагается в рамках CloudLine.
Уведомление рассылается в обязательном порядке всем клиентам (на email, указанный при регистрации) непосредственно перед работам с указанием примерного времени работ. Об этом также написано в этом пункте.
Гугл вроде говорит, что это SS El Oriente.
Он отходил аж две войны :)
Фиксация нарушений SLA будет проходить на основании нашей системы мониторинга и обращений клиента на support@cloudlite.ru.
сами назначают цену одного часа аренды ресурсов. Победитель получает незадействованные ресурсы по его цене. Однако как только на ресурсы снова появится спрос или ставка будет перебита, то эти ресурсы больше не ваши. Как-то так.
В этой публикации мы рассмотрели методы борьбы с петлями, испытанные нами на практике.
Построение Ethernet фабрик (мы используем FabricPath) — один из способов борьбы с петлями и один из приемлемых вариантов соединения ЦОД по L2 без угроз возникновения закольцованностей (проверено в боевых условиях).
VCS и Qfabric упомянуты как альтернативы FP, и мы не ставили цели перечислять все существующие технологии.
Именно на фоне всплеска трафика на L2 коммутаторах CPU может грузить и MAC-learning.
В вашем примере с серверами при правильной настройке портов коммутатора можно смягчить последствия шторма, применив storm-control и ограничив количество обрабатываемых пакетов процессором с помощью инструмента CoPP.
Также можно настроить на порту Layer 2 ACL, разрешив трафик только с MAC-адреса этого сервера.
В статье хотели показать, что Qfabric является вариантом TRILL в отношении формирования единой фабрики без угрозы возникновения петель коммутации внутри этой фабрики. Спасибо за уточнение, поправили этот момент в тексте и еще добавили VCS от Brocade.
2. Для того, чтобы избежать флуда на соседний ЦОД, необходимо разграничение на L3 (по маршрутизации), например, организовать связь между ЦОД через L3VPN. Для нас этот вариант не подходит, т.к. между ЦОД требуется растянутый L2 сегмент для работы vMotion.
Мы выбрали FabricPath, протокол достаточно надежен и прост в эксплуатации (легко настраивается, достаточно быстро можно добавлять новые VLAN). За 2 года эксплуатации ни разу не подвел.
При необходимости подключения в схему третьего ЦОД, можно будет рассмотреть возможность перехода на OTV + FabricPath.
Да, здесь допущена неточность в формулировке. Широковещательный шторм как правило сопровождается ростом количества пакетов в сети (multicast, broadcast, unknown unicast). Поправили. Спасибо)
Температурный режим в помещении аккумуляторной, так же как и в других технологических помещениях, поддерживается в необходимых рамках и постоянно мониторится.
Мертвый АКБ в группе определяется автоматическими тестированиями, которые проводят сами ИБП, и дополнительными тестированиями, которые проводятся в рамках ТО.
Это полностью самописная вещь — сами рисовали, сами кодили :)