Мы много пишем об оборудовании и инфраструктуре, но до сих пор мало внимания уделяли сервисам, которые получают клиенты Huawei. Сегодня мы расскажем, сколько русскоязычных инженеров работает в поддержке Huawei, что такое Smart NOS, Smart IDC и как наши глобальные центры передают друг другу задачи вслед за Солнцем.

Продолжаю ковырять автоматизацию рутины на сети из Huawei коммутаторов. На этот раз изыскания, которые позволили сократить код в 3 раза, а именно: хосты и команды перенесены в отдельные файлы, пароль и имя пользователя больше не хранятся в открытом тексте. Есть демонстрация запуска скрипта. Детальное описание за кнопкой «Читать далее».

Автомобильные радары. От лабораторных образцов до коммерческих продуктов и тенденции их развития.

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

Продолжаем наш марафон бесплатной сдачи сертификационных экзаменов Huawei. Тема сегодняшнего материала – направление HCSA – IP Network. Разбираем учебный материал, изучаем продуктовые линейки маршрутизаторов, коммутаторов и пр. Одна презентация, один экзамен – и сертификат в руках.

До конца года еще есть время бесплатно сдать сертификационный экзамен Huawei по одному из шести доступных направлений. Профильные эксперты компании помогут быстро усвоить учебный материал и повысить шансы на успех. Сегодня разбираемся с направлением HCSA – Intelligent Collaboration.

До конца года осталось совсем немного времени, но его хватит на то, чтобы вплоть до 31 декабря бесплатно получить несколько сертификатов Huawei и принять участие в конкурсе, призами в котором являются носимые гаджеты HUAWEI Band 6 и HUAWEI Watch Fit. Под катом вы найдете все детали конкурса, а также полезные советы по сдаче экзаменов.

Ethernet или Fibre Channel? Можно ли построить центр обработки данных на основе единой сети NVMe over Fabrics, которая будет быстрее и дешевле классических решений? Можно ли обслуживать такую сеть одной командой вместо трех? Можно, если выбрать правильный протокол. Рассказываем, как это сделать.

В работе построена объектная имитационная модель пула потоков, за основу которой взята реализация, используемая в СУБД MySQL, MariaDB и Percona Server. Описаны входные потоки модели и примеры их распределений. Приведены результаты апробации модели, согласующиеся с известными паттернами зависимости производительности от входных параметров. Практическое значение модель имеет как инструмент статического и динамического выявления наиболее значимых для производительности параметров и их оптимального выбора.

Способны ли ARM-серверы эффективно работать в качестве высоконагруженного решения для PostgreSQL 13? Мы провели целый ряд синтетических тестов, сравнивая их с аналогичным оборудованием на платформе x86, и пришли к интересным результатам. Описание методики тестирования и выводы вы найдете под катом.

Зачем я это читаю?

TL;DR:

• Переложив секции кода и данных программы на большие страницы можно существенно ускорить приложение (у нас получилось до +10%) не трогая исходный код.
• Можно быстро проверить ничего не перекомпилируя, детали здесь.
• Финальное решение оперирует "классическими" большими страницами (не transparent huge pages), поэтому в какой-то степени его можно назвать дальнейшим развитием libhugetlbfs.

«Программно-определяемые глобальные сети сложны, дороги и небезопасны. Мы лучше пока посидим на классической инфраструктуре. Вот только наделал бы кто-нибудь много хороших сетевых инженеров — тогда заживем». Нам регулярно доводится слышать такое от CTO крупных компаний с большими ИТ-бюджетами. И все эти утверждения неверны.

Идентификация, балансировка и управление: Рассказываем о 10+ технологиях, которые использует Huawei, чтобы обеспечить бесперебойную работу бизнес-приложений в распределенных корпоративных сетях SD-WAN.

Наше с вами современное время во всех учебниках истории уже названо периодом очередной смены производственного уклада или четвертой промышленной революцией (Индустрией 4.0). Основную роль при этом отводят информации, в том числе ИТ-системам. В попытках удешевления ИТ-инфраструктуры, унификации и ускорения процессов разработки ИТ-решений человечество сначала придумало «облака» на замену традиционным ЦОДам, а затем и контейнеры на замену виртуальным машинам.

Что же такое контейнер и в чем состоит суть контейнеризации?

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

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

Главной и практически единственной значимой целью контейнеризации является также достижение максимально возможной изоляции процессов как друг от друга, так и от возможного негативного воздействия на операционную систему, в которой они исполняются. Иногда в литературе для описания этой изоляции используются термины “sandbox” – «песочница» и “jail” – «тюрьма».

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

- возможность более гибкого использования имеющихся ресурсов (нет необходимости их резервирования как в случае с виртуальными машинами);

- возможность экономии ресурсов (нет необходимости их тратить на множество копий ОС для каждой виртуальной машины);

- нет задержек при старте (запуск процесса происходит практически мгновенно по сравнению с временем, затрачиваемым на загрузку виртуальной машины);

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

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

Виктор Живицкий на момент описанных здесь событий имел двадцатилетний опыт в сетевой инженерии. У него была жена, дочь и рабочая виза в Таиланде. Когда в 2015 году в центре Бангкока прогремел взрыв, он потерял и жену и дочь. Он не смог вернуться к работе, начал забывать спать, есть, и стал находить себя среди незнакомых мест, дорогу к которым кветиапин и венлафаксин исправно вычёркивали из памяти. Когда и медстраховка исчерпала себя, Виктор был в том же состоянии, в которое его погрузила весть о гибели жены и дочери: он крепко отсутствовал в себе.

Жизнь не щадит слабых и сломленных. Виктор быстро скатился до бродяжничества. Иногда он появлялся у кофейни Eiah Sae 益生 на улице Phat Sai, у таицев знаменитой тем, что однажды её посетил член королевской семьи (о чём есть фотография в огромной позолоченной рамке прямо над кассой), у китайцев же известной за лучший кофе в Бангкоке. По обеим из этих причин эту кофейню посещал Д., который во время пандемии организует фонд помощи соотечественникам и поможет множеству людей, застрявшим в Таиланде. 

В один из дней Д. заметил Виктора и подошёл к нему. 

Эта встреча заронила зерно выздоровления в больную душу Виктора и тысячу бат в его карман на дорогу в буддийский монастырь. Так началось его путешествие, о котором ваш покорный слуга узнает по нескольким траблшутинг-постам на форуме Huawei. С Виктором удастся связаться, получить от него эту историю и опубликовать здесь с его согласия, не изменив ни слова. Эта история о том, как знания после десятилетий практики стали частью самого человек, и, может быть, помогли выстоять ему в трагедии, из-за которой лучшая часть его души была вырвана безвозвратно.

Тоннель EOIP (обычно применяемый одним известным брендом) не пропускает BDPU по умолчанию. А это значит, что если протащить VLAN через EOIP, закольцуя его в целях резервирования, то не стоит надеяться, что STP его отработает. Случится петля. Коммуникации в этом VLAN не произойдет - каждый из коммутаторов возомнит себя королем и voilà - сеть стоит на коленях. Если вы знаете как настроить EOIP на пропуск BPDU, то, пожалуйста, напишите об этом в комментарии! Эта информация будет полезна.

Топология Spanning Tree возникает благодаря BPDU (Bridge Protocol Data Unit). Это то, что делает возможным свободную от петель коммуникацию на сети с избыточными линками. И наверное, первое, что нужно сделать перед созданием избыточного линка, будь он логическим или физическим, - это проверить есть ли обмен BPDU между коммутаторами.

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

Каждое это слово содержит информацию об отправителе. Этой информацией они делятся - так они узнают друг о друге и решают, кто будет главным в семье: кто альфа, а кто омега. И главное, на что коммутаторы смотрят - это идентификатор Bridge ID (Bridge Identifier). Каждый из коммутаторов, который имеет включенный Spanning Tree Protocol, несет этот идентификатор. И есть три элемента, которые являются частью этого идентификатора и делают его уникальным для каждого коммутатора. Первый из них - это приоритет (Priority). Его значение по умолчанию равно 32768. (Сколько бит будет задействовано, чтобы получить такое значение?). А если так, то все коммутаторы, настроенные по умолчанию, будут иметь равные шансы стать альфой в семье, так? Нет! Тут вступает в роль второй элемент. Это номер VLAN’a. Коммутатор приплюсует номер VLAN’a к приоритету. Например, если номер VLAN’a - 7, то Bridge ID будет равен 32768 + 7 = 32775. Но и это не сделает коммутатор королем, даже если оба коммутатора имеют VLAN 7. Поэтому знакомьтесь с третьми элементом - MAC address, совершенно уникальным идентификатором.