Pull to refresh
0
0
Send message
Набросок хороший, но деталей мало.
Мы например используем Cisco FP, честно скажу — сомнительное счастье в купе с VPC+. Много раз приводило к дизастеру.
Начали думать за VXLAN/EVPN, благо железки позволяют.
Механика понятна. Вопрос был именно к программной части, тк выглядит очень прилично.
Добрый вечер!
Можете подсказать чем осуществляете мониторинг? Если это конечно не секрет.
Очень любопытно )))
https://www.youtube.com/watch?v=TGgOrUqxSSA
Привет! У нас есть целая стратегия по этому поводу, немного может «кривая», но в целом рабочая. Ниже выдержка:

1.1 Методика определения класса обслуживания технических средств ИС
В состав технических средств обеспечивающих функционирование ИС входят виртуальные серверы выполняющие различные роли при работе пользователя с информационной системой.

Для обеспечения оптимальной утилизации вычислительных ресурсов ЕИТО, был разработан классификатор, позволяющий на основании профиля нагрузки определить оптимальный уровень переподписки вычислительных ресурсов. Профилирование виртуальных серверов необходимо для динамического распределения нагрузки между всеми виртуальными серверами работающими в кластере системы виртуализации.

Для классификации технических средств ИС применяются три профиля нагрузки:
− Серверы с высокой нагрузкой – HL-LL;
− Серверы с средней нагрузкой – ML;
− Серверы с низкой нагрузкой – SL.

Профили нагрузки составлены с учётом характера нагрузки создаваемой виртуальными серверами входящими в состав ИС.

При выборе профиля нагрузки учитываются следующие аспекты:
− характер использования ЦП;
− характер использования ОЗУ;
− характер нагрузки на СХД.

Характер использования ресурсов позволяет более точно произвести настройку системы виртуализации, что обеспечивает наиболее приемлемый уровень утилизации физических ресурсов ЕИТО.

В разделах 2.1.1.1, 2.1.1.2, 2.1.1.3 приведены сведения необходимые для определения характера нагрузки на каждый компонент виртуального сервера.

1.1.1.1 Классификация использования ЦП
Для профилирования использования ресурсов ЦП, в классификатор введены переменные симметричности, равномерности использования и номинальной нагрузки позволяющие наиболее точно определить характер использования ресурсов.

Симметричность – отражает равномерность одновременного использования всех ЦП в многопроцессорных конфигурациях.

Возможные значения критерия:
− Симметричная (Средняя разница в утилизации для самого загруженного и самого не загруженного ЦП не превышает 20%);
− Асимметричная (Средняя разница в утилизации для самого загруженного и самого не загруженного ЦП превышает 20%).

Равномерность – отражает краткосрочные (от 1 мс до 10 мин.) изменения нагрузки не менее чем на 25% в сторону увеличения относительно номинальной нагрузки или до полной утилизации ЦП.

Возможные значения критерия:
− Равномерная (Значения краткосрочных изменений не превышают установленных или идут с периодичностью более 10 мин.);
− Неравномерная (Значения краткосрочных изменений превышают установленные).

Номинальная нагрузка – отражает средний уровень нагрузки в часы максимально использования ИС (с 8.00 до 18.30), без учёта циклических снижений нагрузки. Возможные значения критерия:
− Низкая (Нагрузка менее 50%);
− Высокая (Нагрузка более 50%).
1.1.1.2 Классификация использования ОЗУ
При формировании профиля использования ресурсов ОЗУ был выбран только один параметр – характер выделения, т.к. для разных типов приложений необходимо предусматривать возможность монопольного выделения ОЗУ, ввиду высокой нагрузки или интенсивности изменения страниц памяти приложениями.

Характер выделения – отражает поведение среды виртуализации при выделении адресного пространства ОЗУ для виртуального сервера.
Возможные значения критерия:
− Монопольный (При включении виртуального сервера реальное адресное пространство ОЗУ выделяется одномоментно. Режимы swap и balloon среды виртуализации не используются);
− Разделяемый приоритетный (При включении виртуального сервера реальное адресное пространство ОЗУ выделяется по мере потребления. Режимы swap и balloon среде виртуализации не используются);
− Разделяемый неприоритетный (При включении виртуального сервера реальное адресное пространство ОЗУ выделяется по мере потребления. Используются режимы swap и balloon среде виртуализации).
1.1.1.3 Классификация нагрузки на СХД
Для профилирования нагрузки на ресурсы СХД были использованы два показателя, тип операций ввода-вывода и их интенсивность.

Тип операций ввода-вывода – отражает соотношение между операциями чтения и записи а так же их взаимную зависимость друг от друга. Зависимость операций подразумевает необходимость последовательного выполнения операций ввода-вывода.

Возможные значения критерия:
− Однородный (Выполняются преимущественно операции одного типа в последовательном или параллельном режиме);
− Неоднородный (Выполняются операции разных типов в пропорциях не менее 40/60).

Интенсивность операций – отражает среднюю интенсивность операций ввода-вывода за период с 8.00 до 18.30.
− Высокая (среднее значение >100 IOPS);
− Низкая (среднее значение <100 IOPS).
1.1.1.4 Классификатор детерминирования класса обслуживания сервера
Для детерминирования класса обслуживания виртуального сервера используются параметры представленные в п.п. 2.1.1.1, 2.1.1.2, 2.1.1.3.
Каждый из параметров обладает весом для формирования итогового значения переподписки вычислительных ресурсов.

В таблице 2.1.1.4.1 приведены абсолютные веса для каждого параметра входящего в класс обслуживания.
Применение абсолютных весов при классификации обусловлено необходимостью выявления границ каждого профиля, т.к. выбранные параметры использования ресурсов могут сочетать несколько вариантов.

В таблице 2.1.1.4.2 приведены идеальные значения параметров для каждого класса обслуживания, в случае если один или несколько параметров класса обслуживания не подходит для конкретного виртуального сервера, то его профиль определяется по его среднему арифметическому значению.

Согласно расчетам, представленным в таблице 2.1.1.4.2, у каждого класса обслуживания выявлена четкая граница, что позволяет определить класс обслуживания виртуального сервера по диапазону значений.

Диапазон для класса обслуживания SL – от 0% до 28%;
Диапазон для класса обслуживания ML – от 28% до 66%
Диапазон для класса обслуживания HL-LL – от 66% до 100%.

Присвоение профиля по диапазону значений осуществляет исключительно при невозможности однозначно определить класс обслуживания по идеальной шкале.
Я не могу даже представить себе смелость человека который базирует огромную инфраструктуру на фре/линуксе, без поддержки крупных производителей.
Согласен, EVPN тема благая, но надо собирать POC и так тестировать что и как. На практике DCI я столкнулся с большими ограничениями в части MPLS DCI, но намеренно ушел от LISP и DNS based DR. В двух словах не описать, целый проект написан по нашему DCI.
Мы например используем FP внутри площадки, а DCI реализован на VPLS. Получилось очень удобно, но пришлось крутить еще mcLAG.
Забыли про классику — VPLS.
Неа, нам только Ops MGR дает прогноз. Но лучше у ребят из ITDHQ спросите, они знают CF/MIQ вдоль и поперек.
Скорее о anycast. посмотрите как устроен root dns.
в сетевом мире есть такая штука, называется она hot potato routing.
В вашем случае две линейные карты через которые вяжется VSS link нужны для простой отказоустойчивости. Ведь нет гарантии того что не откажет карта или слот? Таким образом вы увеличиваете коэффициент «А», устраняя точки отказа. Представьте ситуацию, отказывает карта на которой у вас повязан VSS? Как будет развиваться ситуация не известно никому, может пройдет split brain, а может ПО преодолеет эту ситуацию путем отключения одной коробки. Вариант перевязывать VSS через SUP тоже смертельный трюк, т.к. если на CP случиться авария, лазеры потухнут автоматически. Так что проще две карты, больше шансов на выживание.

Надувать не надо, надо трезво оценивать бюджет, выводить «А», и говорить руководству бумагой. Вот бумага, «А», такой-то, надо еще вот это и мы закроем вот это, на такой-то период.
Вообще такие истории всегда — мрак неприятные.
С одной стороны архитекторы должны гореть в аду, за такой дизайн сети. 6708 у вас одна, это фатальная ошибка. Отказ CrossBar не такая и редкость, бывали случаи когда не работает слот, но шасси работает нормально. Линейные карты на такой enviroment должны быть всегда дублированы, да это дорого, но это вопрос к коэффициенту «А».

Второй фатал, это решение вывести второй коммутатор на maintense, вопрос напрашивается сам собой — зачем?
Вопрос номер три, почем вы полезли на maintense в одиночку, я имею не вас конкретно, а тех людей которые не запросили тех под на возможность подмоги. Почему вы не оповести их о окне, и не запросили статус ЗИП? Вам крупно повезло что у них вообще SUP оказался, это просто свыше решили не устраивать хардкор.
Вопрос номер четыре, почему дизайн сети не предусматривает преодоление Disaster? Все очень просто, дизайн сети должен быть рассчитан на возможность получения двойного отказа (а именно он у вас и произошел). У меня зреет вопрос, как допустили отсутствие резервных линков между узлами агрегации? Ведь можно сделать легкий setup 10GE -> 1GE, преодолеть двойной отказ с понижением в скорости и дальше продолжить работать над решением сложившейся ситуации?

Можно Вас попросить назвать имена архитекторов/дизайнеров героев. Ну так, на всякий случай, не пускать их близко.
H.323 канул в лету? У меня беда, УПАТС стоит без SIP, только H.323, приходиться сидеть на 1.8…
А перерь давайте ее воткнем в volvo, чую обернется это жутким мракобесием и буйством железки и софта.
Щас тоже будем инсталировать клиенту F400, посмотрим что и как.
Согласен так может показаться, я только рассказал то что видел сам, не более. К тому же мой коллега бывший инженер из Syritel может подвердить мои слова.
Как обычно левые и правые спорят.
Я был в сирии в мае, в дамаске. Я вас уверяю, там сидят люди которые точно знают что они делают и почему именно так. У САС вообще нет щансов против доктора Башера, и это понимают все. Действительно он не станет допускать ошибок которые допустил полковник, беспилотная зона нужна только для одного — авиаудары. Резолюция на БЗ не будет введена ровно до тех пор пока у аврмии доктора есть ПВО которого все боятся. Это раз. Весь трафик которые выходил и входил в страну в обязательном порядке фильтровался, SSL (HTTPS) грызли на лету, я даже почту проверить не мог т.к. у меня сертификаты специально самоподписные, а приходили от VS… (я молчу про то что Ipsec, GRE, Skype просто не работали) Это два. То что нам преподносит пресса — 100% ложь, причем доходило до того — al jazeera вела on line трансляцию с площади где бегали толпы людей и был стихийный митинг, черезе 5 минут я был на площади где стояли два мента и колеки, а там все в прямом эфире. Это три. Ну и на последок армия, полиция и население настолько злые на САС что готовы их уже руками голыми душить.

Кстати, я не призываю к занятию какой-то позиции просто доношу истину как она есть. Без купюр )
FR я привел для примера. У меня был случай когда SP давал VPLS на который мне надо было натянуть OSPF, мультикаст не ходил в принципе, вот и пригодилась NBMA топология…

Information

Rating
Does not participate
Registered
Activity