Русский
Русский
English
Статистика
Реклама

1-3-5

Huawei DCN. Сети ЦОД на основе намерений новые решения по управлению сетями

14.07.2020 14:04:30 | Автор: admin
Постоянное усложнение сетевой инфраструктуры современных ЦОДов ведёт к лавинообразному росту количества параметров, которые нужно контролировать ради оптимальных производительности и надёжности. Повысить уровень информированности администраторов о происходящих в сети процессах и помочь быстро выявлять зарождающиеся проблемы призвана концепция Huawei, воплотившаяся в решениях типа Intent-Driven Network: они предназначены для создания саморегулирующихся и самоуправляемых сетей, отвечающих принципу от автоматизации к автономности.



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



Четыре этапа развития ЦОДа


Определяя вектор развития сетей центров обработки данных, нетрудно заметить, как традиционные архитектуры ЦОДов постепенно пали под натиском систем виртуализации, затем пережили массовую миграцию ресурсов и сервисов в облака, а теперь вплотную подошли к широкому внедрению систем искусственного интеллекта и скоростных интерфейсов 400 Гбит/с. Возможности ИИ необходимы для построения сетей Ethernet без потерь и создания приложений, полностью невосприимчивых к задержкам.

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



В качестве основных инфраструктурных сетевых единиц для построения сетей ЦОД Huawei предлагает сейчас линейку четырёх-, восьми- и шестнадцатислотовых коммутаторов CloudEngine 16800 с аплинками 400 Гбит/с; их выпуск намечен на текущий год. Также среди новинок отметим построенные на нашей собственной элементной базе ToR-свитчи CloudEngine 6881 и 6863 с интерфейсами 10 и 25 Гбит/с соответственно.



На иллюстрации показаны модели коммутаторов из линейки CloudEngine 16800 с классической ортогональной архитектурой, которые оснащены системой охлаждения front-to-back, а также совместимые с ними линейные карты, снабжённые интерфейсами 10, 40 и 100 Гбит/с.

Из важных базовых функций CloudEngine 16800 выделим его умение работать с NSH (Network Service Header), что позволяет реализовать в ЦОДе распределённую по нескольким свитчам микросегментацию (изоляцию на уровне виртуальных машин), обеспечить широкие возможности телеметрии и проводить анализ трафика на границе сети (edge intelligence) с применением технологий искусственного интеллекта на базе AI-чипов Huawei.

По-настоящему революционной станет модель V1R19C10. Именно в ней должны быть реализованы многие давно ожидаемые функции, в том числе EVPN Multihoming без перемычки в виде M-LAG (Multi-Switch Link Aggregation) на основании первого и четвертого типов маршрутов в EVPN-роутинге VXLAN.



Знакомая архитектура и новые возможности


На схеме видна привычная ортогональная архитектура трёхуровневой фабрики Non-blocking Switching. К её первоочередным достоинствам стоит отнести оптимальное расположение плат фабрики, линейных карт, коннекторов и системы обдува, основанной на вентиляторах с переменной скоростью вращения.



Важно, что на новых моделях коммутаторов аппаратно реализован протокол BFD (Bidirectional Forwarding Detection) и есть возможность настройки VXLAN в адресном пространстве IPv6. Базовая архитектура осталась прежней и строится на процессоре, сопроцессоре и forwarding chip. Функциональность каждого из узлов представлена на схеме. Главное же изменение 2020 года переход на собственные чипы Huawei во флагманских коммутаторах, полноценно конкурирующие с аналогами от Broadcom.



Поддержка операций с Network Service Header позволяет новым коммутаторам менять дефолтные маршруты пакетов VXLAN и подключать такие сервисы, как межсетевые экраны (FW), системы обнаружения вторжений (IDS), балансировщики нагрузки (SLB) и NAT.



Вернёмся ненадолго к ранее упомянутой разделённой микросегментации. Новые ToR-коммутаторы Huawei с помощью всё тех же NSH позволяют изолировать рабочие нагрузки на уровне имён виртуальных машин. Эти машины можно дополнительно группировать на уровне подсетей, на основании номеров портов, вышестоящих протоколов и пр., таким образом формируя группы приложений.



Полный спектр телеметрических данных


Информация с устройств собирается в реальном времени с использованием нескольких основных протоколов. Задачей ERSPAN+ является сбор TCP-заголовков для последующего детального анализа TCP-потоков в ЦОДе. Дополнительные данные добываются с помощью протокола gRPC и таблицы переадресации (Flow table). Всё это собирается с Protobuf over UDP.



Основное направление развития средств O&M в Huawei переход от ручного или полуавтоматического контроля сети к полностью автоматическому, основанному на технологиях искусственного интеллекта. Всеохватная система телеметрии достаточно крупной площадки производит огромные объёмы данных, анализ которых в сжатые сроки возможен только с применением ИИ. Особенно это важно в тех ЦОДах, где сбои и простои просто недопустимы.



К превентивным мерам, призванным не допустить возникновения неполадок в работе сети, прежде всего стоит отнести мониторинг здоровья сети: контроль загрузки каналов, выявление причин потери пакетов (допустим, поиск корреляции с временем суток или периодами работы какого-либо приложения), обнаружение узких мест (capacity forecasting) и пр.

Если неполадки всё же наблюдаются, минимизировать время диагностики и восстановления помогает выдвинутый Huawei принцип 1-3-5: минута на поиск, три минуты на локализацию, пять минут на ликвидацию проблемы. Для того чтобы укладываться в эти рамки, продукты Huawei поддерживают постоянно расширяющийся список типовых неисправностей, которые определяются автоматически.



Модель V100R019C10 для небольших ЦОДов


Одним из главных нововведений в V100R019C10 стала поддержка визуализации на основе телеметрических данных во всех типах сценариев. По сути, речь идёт о наглядном отображении любых изменений в сети. Кроме того, устройство теперь умеет определять более 75 первопричин возникновения тех или иных проблем и помогает наметить действия для их устранения (запуск скриптов и пр.).

Важной новостью стало появление версии Standalone, включающей в себя как iMaster NCE, так и FabricInsight и предназначенной главным образом для дата-центров небольшого размера, не требующих нескольких серверов для управления сетью.



Изменения в системе лицензирования


Для лучшего понимания функциональных особенностей FabricInsight следует пояснить, какие изменения произошли в бизнес-модели распространения сетевых продуктов Huawei. Если количество коммутаторов не достигает сотни, такой вариант классифицируется как standalone edition и подразумевает наличие лицензии N1. Кластер из трёх и более серверов уже поставляется в комплекте с платформой аналитики больших данных. Решение Advanced solution, включающее в себя несколько сотен свитчей, рекомендуется использовать совместно с инструментарием для анализа сетевых потоков. Все три варианта допускают использование возможностей FabricInsight при наличии лицензии N1.



Любая лицензия подразумевает применение всего набора телеметрических инструментов и сценариев 1-3-5, за исключением средств анализа TCP-потоков, доступных только в Advanced solution.



Осталось рассказать о конфигурациях серверов, предназначенных для решений Standard и Advanced solution. На сегодняшний день standalone node (один узел) доступен только на сервере Taishan 200. Для работы кластера из трёх узлов необходимо 16 или более вычислительных ядер, 128 Гбайт оперативной памяти и т. д. (см. схему). Объём дата-диска напрямую зависит от того, как долго должна храниться статистика.



KPI-мониторинг


Чуть подробнее остановимся на KPI-мониторинге. Для его применения достаточно задать временной интервал и конкретные пороговые значения, достижение которых будет проверяться на основании полученных телеметрических данных. Доступно много типов метрик, среди которых:

  • использование ЦПУ и памяти;
  • использование FIB / MAC;
  • использование троичной ассоциативной памяти (TCAM) чипа;
  • параметры портов;
  • размер буфера для очереди;
  • разные метрики AI Fabric;
  • уровень сигнала, температура и другие параметры работы оптического модуля;
  • потеря пакетов.




Предварительная проверка


Инструмент предварительной проверки также оперирует данными, получаемыми с помощью телеметрии. CT scanner позволяет понять, происходили ли в сети те или иные нежелательные события. Часть метрик совпадает с метриками KPI-мониторинга фабрики (главным образом касающиеся ёмкости и производительности). Остальные основываются на результатах анализа верхнего уровня (VXLAN, BGP и др.) и анализа конфигурации. После запуска CT scanner собирает необходимые сведения и формирует исчерпывающий отчёт о состоянии сети.



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



Неполадки устройств


Мониторинг позволяет выявлять самые разнообразные проблемы, возникающие на уровне устройств. В рассматриваемом случае объектом проверки является свитч, 36 регистрируемых параметров работы которого дают возможность обнаруживать 29 типов неисправностей.

В таблице на схеме перечислены виды неисправностей; модели коммутаторов, позволяющих FabricInsight обнаружить проблему; используемые FabricInsight функции; автоматические действия, предпринимаемые при обнаружении неполадок (предупреждения, рекомендации, запуск скрипта).



Допустим, у устройства зафиксирована нехватка ресурсов, ведущая к падению уровня сервиса. Данные из системного журнала, объединённые с данными телеметрии FIB-ресурсов, позволяют оперативно оценить ситуацию в режиме ручной проверки.



Возникновение петли на уровне оборудования просто невозможно, так как устройство не позволит внести подобную ошибку в конфигурацию. Однако петля может возникнуть, например, на втором уровне (на уровне виртуальной машины) из-за неправильно настроенного программного свитча, как на представленной выше схеме. С помощью FabricInsight можно не только обнаружить неполадку, но и изолировать нужный участок сети, чтобы исключить его влияние на функционирование всей фабрики.



Неполадки сети


Посредством FabricInsight с опорой на 18 доступных для анализа метрик удаётся выявлять 10 типов сетевых неполадок. На схеме приведён их полный перечень, а также как и в случае с неполадками устройств модели коммутаторов, позволяющих FabricInsight обнаружить проблему, используемые функции и доступные автоматические действия.



Допустим, деградация или неисправность оптического модуля приводит к ухудшению его работы: линк становится нестабильным. Такие ситуации возникают нерегулярно, и их трудно воспроизвести. Из-за этого обнаружение проблемы может занять много времени. Средства FabricInsight дают возможность сразу заметить падение уровня сигнала или изменение напряжения на модуле.



Средствами сетевой диагностики FabricInsight можно своевременно выявить и проблемы с буфером, часто возникающие в системах с большим количеством серверов, которые отведены под обработку big data. Традиционная NMS (Network Management System) проверяет связанные с буфером параметры каждые пять минут. Возможности телеметрии FabricInsight позволяют уменьшить эти интервалы вплоть до 100 мс и выявить даже самые короткие микроинциденты.



Неполадки на уровне протоколов


Здесь FabricInsight умеет определять шесть типов неполадок, включая конфликт двух мастер-свитчей в M-LAG; проблемы взаимодействия соседних коммутаторов и пр. Эта функциональность доступна при использовании коммутаторов V200R005C00 и более новых.



Рассмотрим конфликт мастер-свитчей. При всех достоинствах технологии M-LAG в случае обрыва линка и неисправности одноранговой сети в системе появляются два мастер-свитча. FabricInsight умеет проактивно реагировать на подобную ситуацию благодаря постоянному контролю состояния peer-линка и DFS.



Неполадки оверлейной сети


Семь типов неполадок оверлейной сети могут быть выявлены благодаря контролю десяти различных метрик. FabricInsight умеет проверять статус лицензии VXLAN, находить ошибки в конфигурациях, определять падение sub-интерфейса и т. д. Опции реагирования аналогичны описанным ранее.



Неполадки сервисов


Для выявления шести типов неполадок на уровне сервисов используется контроль семи метрик. Обнаружению поддаются конфликты IP-адресов, проблемы с установлением соединения, флуд-атака TCP SYN и др. Обратим внимание на то, что для поддержки этих возможностей FabricInsight может понадобиться наличие анализатора TCP-потоков.

При более широком взгляде на вопросы поиска неполадок видно, что FabricInsight это не просто средство сбора данных с устройства, но и расширяемая библиотека сценариев, нацеленных на решение проблем самых разных типов.



От автоматизации к автономности


В качестве резюме скажем, что в основе идеологии Intent-Driven Network лежит трёхступенчатая модель реагирования, которая включает в себя сбор информации, её анализ с привлечением средств ИИ и предложения по изменению состояния сети, в том числе в автоматическом режиме.

***


Напоминаем о том, что наши эксперты регулярно проводят вебинары по продуктам Huawei и по технологиям, которые в них используются. Список вебинаров на ближайшие недели доступен по ссылке.
Подробнее..

Huawei ADN первая в индустрии сеть с автономным управлением третьего уровня

28.04.2021 16:12:49 | Автор: admin
Что такое автономно управляемая сеть и чем она отличается от SDN? Huawei совместно с консалтинговой компанией IDC изучила критерии оценки сетевой инфраструктуры по уровню её способности поддерживать собственную работу без помощи администратора.



Какой заказчики хотят видеть сетевую инфраструктуру ЦОДа? Она, конечно, должна быть эффективной, надёжной и простой в обслуживании. Совсем чудесно было бы, если бы сеть настраивала и обслуживала себя сама. Современные SDN-контроллеры умеют всё больше, но как оценить уровень их автоматизации? Как классифицировать эту автономность?

Чтобы ответить на эти вопросы, мы обратились в консалтинговую компанию IDC и попросили её провести исследование, по результатам которого можно было бы понять, как охарактеризовать автономность управления той или иной сетью и как оценить эффективность подобного внедрения. Коллеги из IDC откликнулись на наше предложение и пришли к интересным выводам.



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

Между тем не следует рассматривать облако просто как место выполнения рабочих нагрузок. Это ещё и особые подходы к работе, подразумевающие высокий уровень автоматизации. По мнению аналитиков IDC, мы вступаем в эпоху множества инноваций. Компании инвестируют в такие технологии, как искусственный интеллект, интернет вещей, блокчейн и интерфейсы естественного взаимодействия. Но конечная цель это именно автономность систем и инфраструктур. В таком контексте и следует оценивать перспективы развития сетей ЦОД.



На схеме изображён процесс автоматизации сетей, который делится на несколько последовательных этапов. Он начинается с интерфейса командной строки и создания скриптов. На следующем этапе появляются сетевые фабрики, позволяющие повысить скорость и производительность. Далее наступает пора SDN-контроллеров и средств виртуализации. На этом этапе также внедряются инструменты оркестрации и автоматизации сетей ЦОД.

Качественно новым уровнем является переход к сетям, управляемым на основе намерений (intent-based networking). Но целью этого прогресса является создание полностью автономной сети, управляемой искусственным интеллектом. Все участники рынка так или иначе рассматривают эту задачу.

Что же такое автономность сети и как её оценить? Компания IDC предложила шестиуровневую модель, позволяющую точно отнести конкретное решение к тому или иному уровню автономности.

  • Level 0. На этом этапе управление сетью осуществляется только через ручные процессы на протяжении всего жизненного цикла сети. Сеть не является автоматизированной.
  • Level 1. Управление сетью всё ещё преимущественно ручное на протяжении всего жизненного цикла сети.
  • Level 2. В некоторых сценариях появляется частичная автоматизация, которая сочетается со стандартными инструментами анализа и управления политиками.
  • Level 3. Условная автоматизация. Система уже умеет выдавать рекомендации и указания, принимаемые или отклоняемые оператором.
  • Level 4. Сеть в значительной мере автоматизирована и автономна. Управляется она декларативными методами на основе намерений. Оператор лишь получает уведомления о событиях и принимает решения о принятии или отклонении рекомендаций сети.
  • Level 5. Сеть полностью автоматизирована и автономна на протяжении всего жизненного цикла. Она способна самостоятельно применять политики, устранять неисправности и восстанавливать сервисы.




С какими же основными вызовами сталкивается компания, внедряющая инновации в сетях ЦОД? По данным IDC, собранным на основе опросов IT-экспертов, на первом и втором местах находятся согласование уровня автоматизации сети с уровнем автоматизации систем вычисления и хранения, а также обеспечение гибкости, то есть способности сети поддерживать смешанные рабочие нагрузки и среды.

На третьем месте проблема автоматизации сетевой инфраструктуры, которая, как чаще всего и бывает, собрана из продуктов различных вендоров. Здесь требуется средство управления, способное собрать воедино весь зоопарк решений и заставить его работать в соответствии с требуемым уровнем автономности. При этом 90% опрошенных согласны с тем, что достижение автономности сети является целью их организаций.

Исследование IDC показывает, что автономное управление сетью является остроактуальным трендом, в который так или иначе вовлечено до половины всех компаний, занимающихся развитием своей IT-инфраструктуры.



Рассмотрим в качестве примера цифровой трансформации компании финансового сектора. За последний год продажи в офлайне радикально уменьшились, и финансовые организации отреагировали на это одними из первых.

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



Вместе с тем инновации в работе с клиентами повлекли за собой повышение сложности IT-инфраструктуры и увеличение частоты вносимых в неё изменений. До 50% сложных проблем, регистрируемых сейчас в ЦОДах, в той или иной мере обусловлены ограниченностью как самих сетевых ресурсов, так и ресурсов команды администраторов.

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

Пожалуй, это объясняет следующую цифру: до 40% сложных проблем в ЦОДах вызваны человеческими ошибками. Любые изменения в сети, как то: запуски новых приложений, развёртывание сервисов и т. д., требуют большого внимания и многочисленных проверок, на которые далеко не всегда хватает рабочего времени. Итогом может стать серьёзная авария в ЦОДе.

А сколько времени тратится на разрешение той или иной проблемы? Наши данные говорят о том, что в среднем для одного только обнаружения неисправности требуется почти 80 минут. И неисправности эти далеко не всегда связаны с физическими устройствами. Они могут происходить на уровне протоколов, доступности сервисов и пр.

В итоге поддержка сети работает днём и ночью, но всё равно становится мишенью для многочисленных жалоб. Для многих из них не было бы оснований, если бы сеть ЦОДа приобрела некоторую автономность.



Вернёмся к классификации уровней автономности, предложенной IDC. Перед вами перечень возможностей, которые сеть должна демонстрировать на каждом из этих уровней. Решение Huawei Autonomous Driving Network отвечает всем требованиям третьего уровня. Она умеет в полностью автоматическом режиме поддерживать свою работу, включая запуск и остановку процессов, настройку оборудования и пр. Кроме того, наша ADN в полной мере соответствует критерию осведомлённости, в реальном времени получая информацию о состоянии устройств, процессов, приложений и сервисов.

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

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

В соответствии со своим roadmap к 2028 году мы будем располагать системой, полностью соответствующей пятому уровню автономности.



Каким же будет эффект от внедрения автономного управления сетью? Начнём с проектирования сети. В случае использования Huawei Autonomous Driving Network заказчику нет необходимости вручную создавать архитектуру или дизайн, а также настраивать устройства. Система лишь просит указать, какое количество устройств и линков определенной пропускной способности должно быть задействовано. Затем она автоматически собирает сетевую инфраструктуру и предлагает её в виде готового решения. Заказчик сразу же получает полностью работоспособную фабрику дата-центра.

Но мало получить сетевую инфраструктуру. Она должна обеспечить работоспособность виртуальных машин, приложений и прочих процессов, каждый из которых предъявляет свои требования к пропускной способности тех или иных каналов. Автономная сеть может проанализировать нагрузку и дать рекомендации по оптимальной организации информационных потоков.

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

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

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



Сила Huawei Autonomous Driving Network в том, что это не просто программное обеспечение, которое можно проинсталлировать и получать сервис. В системе реализована трёхуровневая модель, базовый уровень которой расположен уже на уровне процессоров конечных устройств коммутации и маршрутизации. Эти программно-аппаратные элементы выполняют задачи по сбору и анализу данных, а также коммутации потоков и кадров. Оснащённый таким процессором коммутатор в режиме реального времени передаёт информацию в направлении программной платформы, в качестве которой в нашем случае выступает iMaster NCE.

Именно архитектура нашей ADN отличает её от других сопоставимых продуктов. Интеграция с аппаратными элементами позволяет проводить уникальный по глубине анализ, давая возможность реализовать процессы автоматической настройки дизайна сети, инсталляции сетевых устройств и пр. Можно, например, создать виртуального двойника приложения и провести верификацию сервиса в существующей инфраструктуре. Результатом станет детальный отчёт, включающий в себя перечень потенциальных мест возникновения проблем.

Осталось отметить, что ADN является сервис-ориентированным решением, широко использующим возможности облачных технологий. Выше мы уже говорили о том, что на пятом уровне автономности сеть должна уметь использовать алгоритмы борьбы с неисправностями, сформированные на основе опыта других заказчиков и отраслевых экспертов. Именно из облака ADN вскоре научится получать решения для тех или иных сетевых проблем, идентифицируемых на основе сигнатур.

Подходы, использованные при создании ADN, позволяют в очередной раз вспомнить наш принцип 1-3-5: любая проблема в сети должна быть выявлена за одну минуту, локализована за три минуты и исправлена за пять минут.



Подведём итог. Конечно, ADN является преемницей решений, заложенных в SDN. Это был необходимый этап развития технологии, но в нём крылись некоторые недостатки. Во-первых, использование программно-определяемых сетей подразумевало ручную первичную настройку устройств. Во-вторых, выявление ошибок также ложилось на плечи специалистов по поддержке сети. В-третьих, в случае с SDN, конечно, не шла речь об автоматическом применении сценариев восстановления, полученных из облачной базы знаний. Создавая своё ADN-решение, Huawei стремилась к тому, чтобы наши клиенты освободились от этих задач, сосредоточившись на том, что действительно требует внимания.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru