Pull to refresh

Comments 11

Спасибо, полезный опыт.

Зачем потребителю облака функционал VLANов, если эту задачу выполняет NVGRE?
Некоторые сценарии, например, IP-телефония, чувствительны к фильтрам и не очень хорошо работают.
Но, главное, сила привычки.
Вот лучшая иллюстрация: www.youtube.com/watch?v=LP0g9d3lO4Q
То есть, например, виртуальный E-SBC на NVGRE лучше не вешать?
Простите, никак не пойму, что Вы разнесли по разным серверам? :))
Базу данных и все остальное на одном сервере? :))
Сами сервисы Azure Pack, SPF, а также RDG шлюз и база данных под Azure Pack могут быть развернуты на одном сервере.
Мы предпочли разнести по разным.
Простите, но это смешно ;)
У WAP'а 23, чтоли, компонента (речь только про WAP, не про «смежные» ресурсы), которые могут быть разнесены по разным серверам и высокодоступны при этом. А у вас что? падает что-либо = падает все. Это действительно Ваш продакшн, на котором живые клиенты, которые платят деньги?

Пс. Чисто теоретически, наверно, можно засунуть и WAP и SPF на одну машину, но я уверен что это не рекомендуется делать.
Отказоустойчивость систем управления достигается отказоустойчивостью инфраструктурного кластера под ними.
У Вас что даже VMM не кластеризован?!
пс. Failover Cluster не обеспечивает устойчивость к отказу сервисов на нем размешенных.
Тогда еще такой вопрос, Вам правда помогал MS Consulting развернуть такое решение?
Вы не поймите меня не правильно, я не критикую, я просто пытаюсь понять. Я далек очень от реалий бизнеса, я привык читать White Paper'ы где под обслуживание частного облака отводится 4 хоста Hyper-V, где все разнесено по виртуалкам и дублируется (как минимум), где полное разворачивание Azure Pack'а занимает 20+ виртуалок, где используется SQL Always-On в качестве БД, где ресурсы, которые выставлены «наружу», не в домене и т.д.

А можете рассказать на какую нагрузку Вы расчитываете?
По системам управления, есть желаемое (план), есть действительное (факт) и есть путь от одного к другому. У нас сейчас как раз применен принцип разумной достаточности: отказоустойчивость реализована, балансировка нагрузки, для чего, собственно, во-многом, кластеризуются элементы, сейчас не требуется.
И потом, мы говорим о системах управления, а не о самой инфраструктуре, SLA на управление спокойно может быть немного ниже, хотя у нас это не так.

План текущей очереди инфраструктуры «несколько тысяч виртуальных машин», подробнее не могу. И мы и не строим одну бесконечно расширяемую инфраструктуру. Это совершенно не нужно в реалиях локального рынка.
Sign up to leave a comment.