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

Сетевые технологии

Прокладываем L2 туннели в OpenVPN

03.07.2020 12:17:33 | Автор: admin

Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных из коробки универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.

Почему именно L2?


Этим вопросом я задался в первую очередь: я довольно редко работаю с сетевой периферией, и мне казалось что довольно давно уже всё оборудование умеет ходить по L3. Как бы не так: кому-то нужен доступ к офисным принтерам, кому-то к видеорегистраторам, а кто-то просто хочет зарубиться с другом в LAN-дуэли не выходя из дома, разумеется. Также очень привлекательной выглядит идея общих/сетевых папок в офисе, доступных из дома, особенно в период повальной удалёнки.

При этом среди разработчиков VPN-клиентов L2-бриджи почему-то считаются чем-то вроде странного каприза одного-двух процентов пользователей, который по большому счёту никому не нужен. Совсем иначе обстоят дела в промышленных сетях, где много устаревшего или плохо совместимого оборудования, и концепция L2VPN (представленная кучей других аббревиатур) реализована на уровне сети и оборудования провайдера.

Технологии


Их много, и они все работают со странностями и ограничениями:

  • Например, протокол Layer 2 Tunneling Protocol (L2TP) должен, судя по названию, обеспечивать поддержку OSI L2 и в том числе проброс broadcast'a. Но нет, общепринятая связка L2TP + IPsec не позволяет бриджевать сети на уровне L2!
  • PPTP стал мемом из-за крупных уязвимостей, сейчас кое-как починен, но к L2 уже не имеет отношения.
  • MPLS жутко запутанный промышленный протокол на основе меток. Изучить его сложно, а поднять можно только на специализированном железе или RouterOS (с ограничениями, куда ж без них).
  • PPPoE и феерический PPPoEoE тоже работают, но на проприетарных железках. Режим PPPoE вообще есть на многих роутерах, но как его правильно готовить известно по большей части только на фирменном оборудовании типа Cisco.
  • EoIP должен быть стать тем самым L2VPN made right, но он тоже работает только на микротиках, что существенно сужает круг применения. Как и PPTP, использует GRE, не проходит через NAT.

И тут я с удивлением обнаружил, что настоящий Ethernet Bridging умеет OpenVPN!

Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.

Настройка


Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине это никому не нужно. Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.

Установка


Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:

apt update && apt -y install ca-certificates wget net-tools gnupgwget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.listapt update && apt -y install openvpn-as

После установки сервер поднимется самостоятельно, вы увидите такое сообщение:

+++++++++++++++++++++++++++++++++++++++++++++++Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_asConfiguration log file has been written to /usr/local/openvpn_as/init.logAccess Server Web UIs are available here:Admin  UI: https://185.209.31.165:943/adminClient UI: https://185.209.31.165:943/+++++++++++++++++++++++++++++++++++++++++++++++

Сразу нужно указать пароль для админской учётки:

passwd openvpn

Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.



AS бесплатна для использования двумя пользователями, дальше можно добавлять только за $18/месяц за одного пользователя, так что лучше сразу спроектировать свои процессы под использование туннеля двумя клиентами.

Возвращаем бриджинг


cd /usr/local/openvpn_as/scripts./sacli --key "von.general.osi_layer" --value "2" ConfigPut./sacli start

Если всё прошло успешно, в выведенном json'е будет такое:

{ "errors": {}, "last_restarted": "Thu Jul  2 00:07:37 2020", "service_status": {   "api": "on",   "auth": "on",   "bridge": "on",        ...    }}

В админке статус OSI Layer: 3 (routing/NAT) поменяется на 2 (bridging)

NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему не разбирался, безопасные в этом плане версии около 2.4

Собственно на этом ноу-хау заканчивается, дальше вам нужно просто настроить под себя сервер, завести второго пользователя через тот же веб-интерфейс и залогиниться на пользовательскую страницу на 943 порту (без /admin). Там будут ссылки на скачивание клиентов OpenVPN Connect под все платформы с запечённым конфигом для подключения (кроме мобильных приложений, там придется вбить адрес вручную, а дальше всё само установится).



После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.

Подробнее..

Recovery mode Улучшение параметров безопасности SSL-соединения в Zimbra Collaboration Suite Open-Source Edition

26.06.2020 14:09:33 | Автор: admin
Надежность шифрования является одним из наиболее важных показателей при использовании информационных систем для бизнеса, ведь ежедневно они участвуют в передаче огромного количества конфиденциальной информации. Общепринятым средством оценки качества SSL-соединения является независимый тест от Qualys SSL Labs. Поскольку данный тест может запустить кто угодно, для SaaS-провайдеров особенно важно, чтобы оценка в этом тесте была максимальной. О качестве SSL-соединения заботятся не только SaaS-провайдеры, но и обычные предприятия. Для них данный тест является отличной возможностью выявить потенциально уязвимые места и заблаговременно закрыть все лазейки для киберпреступников.

image

В Zimbra OSE допустимо использовать два вида SSL-сертификатов. Первый это самоподписанный сертификат, который автоматически добавляется при установке. Этот сертификат бесплатен и не ограничен по времени использования, а значит идеально подойдет для тестирования Zimbra OSE или ее использования исключительно в рамках внутренней сети. Однако при входе в веб-клиент пользователи будут видеть предупреждение от браузера, что данный сертификат ненадежен, и тест от Qualys SSL Labs ваш сервер однозначно провалит.

Второй это коммерческий SSL-сертификат, подписанный удостоверяющим центром. Такие сертификаты без проблем воспринимается браузерами и обычно используются при коммерческой эксплуатации Zimbra OSE. Сразу после корректной установки коммерческого сертификата Zimbra OSE 8.8.15 показывает оценку A в тесте от Qualys SSL Labs. Это отличный результат, но наша цель достигнуть результата A+.





Для того, чтобы достичь максимальной оценки в тесте от Qualys SSL Labs при использовании Zimbra Collaboration Suite Open-Source Edition необходимо выполнить ряд шагов:

1. Увеличение параметров протокола Диффи-Хеллмана

По умолчанию во всех компонентах Zimbra OSE 8.8.15, которые используют OpenSSL, значение параметров протокола Диффи-Хеллмана составляет 2048 бит. В принципе, этого более чем достаточно для получения оценки А+ в тесте от Qualys SSL Labs. Однако, в том случае, если вы обновляетесь с более старых версий, значение параметров может оказаться ниже. Поэтому рекомендуется после завершения обновления выполнить команду zmdhparam set -new 2048, которая повысит параметры протокола Диффи-Хеллмана до приемлемых 2048 бит, а при желании при помощи этой же команды можно повысить значение параметров до 3072 или 4096 бит, что с одной стороны приведет к увеличению времени генерации, однако с другой стороны положительно скажется на уровне безопасности почтового сервера.

2. Включение рекомендованного списка используемых шифров

По умолчанию Zimbra Collaborataion Suite Open-Source Edition поддерживает широкий спектр сильных и слабых шифров, при помощи которых шифруются данные проходящие по защищенному соединению. Однако использвоание слабых шифров является серьезным минусом при проверке безопасности SSL-соединения. Для того, чтобы этого избежать, необходимо настроить список используемых шифров.

Для этого следует воспользоваться командой zmprov mcf zimbraReverseProxySSLCiphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4'.

В эту команду сразу включен набор рекомендованных шифров и благодаря ей команде можно сразу включить в список надежные шифры и исключить ненадежные. Теперь остается только перезагрузить узлы с обратными прокси с помощью команды zmproxyctl restart. После перезагрузки внесенные изменения вступят в силу.

В том случае, если этот список вас по тем или иным причинам не устраивает, можно удалить из него ряд слабых шифров с помощью команды zmprov mcf +zimbraSSLExcludeCipherSuites. Так, например, команда zmprov mcf +zimbraSSLExcludeCipherSuites TLS_RSA_WITH_RC4_128_MD5 +zimbraSSLExcludeCipherSuites TLS_RSA_WITH_RC4_128_SHA +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_MD5 +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_SHA +zimbraSSLExcludeCipherSuites TLS_ECDHE_RSA_WITH_RC4_128_SHA, которая полностью исключит использование шифров RC4. Так же можно поступить и с шифрами AES и 3DES.

3. Включение HSTS

Включенные механизмы принудительного включения шифрования соединения и восстановления сеанса TLS также являются обязательными условиями для получения высшего балла в тесте от Qualys SSL Labs. Для их включения необходимо ввести команду zmprov mcf +zimbraResponseHeader Strict-Transport-Security: max-age=31536000. Данная команда добавит необходимый заголовок в конфигурацию, а для вступления новых настроек в силу придется перезагрузить Zimbra OSE с помощью команды zmcontrol restart.

Уже на этом этапе тест от Qualys SSL Labs будет демонстрировать оценку A+, однако если вы захотите дополнительно улучшить безопасность вашего сервера, можно предпринять еще ряд мер.



Например, можно включить принудительное шифрование межпроцессных соединений, а также включить принудительное шифрование при подключении к службам Zimbra OSE. Для проверки межпроцессных соединений следует ввести следующие команды:

zmlocalconfig -e ldap_starttls_supported=1
zmlocalconfig -e zimbra_require_interprocess_security=1
zmlocalconfig -e ldap_starttls_required=true


Для включения принудительного шифрования нужно ввести:

zmprov gs `zmhostname` zimbraReverseProxyMailMode
zmprov ms `zmhostname` zimbraReverseProxyMailMode https

zmprov gs `zmhostname` zimbraMailMode
zmprov ms `zmhostname` zimbraMailMode https

zmprov gs `zmhostname` zimbraReverseProxySSLToUpstreamEnabled
zmprov ms `zmhostname` zimbraReverseProxySSLToUpstreamEnabled TRUE


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



Таким образом, следуя нашим рекомендациям можно не только добиться высочайшей оценки в тесте на безопасность SSL-соединения, но и значительно повысить безопасность работы всей инфраструктуры Zimbra OSE.

По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании Zextras Екатерине Триандафилиди по электронной почте katerina@zextras.com
Подробнее..

Check Point SandBlast Agent. Что нового?

30.06.2020 14:13:12 | Автор: admin


Мы уже опубликовали огромное кол-во обучающих материалов по Check Point. Однако, тема защиты рабочих станций с помощью Check Point SandBlast Agent пока освещена крайне плохо. Мы планируем исправиться и в ближайшее время создать обучающие курсы по этому продукту, который является одним из лидеров сегмента EDR несколько лет подряд. А пока, делимся информацией о новых возможностях агента, которые появились в версии E83.10. Спойлер появилась бета версия под LINUX и новая облачная управлялка.

Новые функции


Все улучшения версии E83.10 можно найти в sk166979. Там много значимой информации, но мы лучше пройдемся по новым функциям.

Новый облачный менеджмент портал


Check Point уже долгое время развивает концепт Infinity, где ключевую роль играет централизованное управление через облачный портал portal.checkpoint.com. На текущий момент есть огромное кол-во сервисов, доступных через этот портал:

  • CloudGuard SaaS
  • Smart-1 Cloud
  • Infinity SOC
  • CloudGuard Connect
  • Threat Hunting
  • SandBlast Mobile
  • и многое другое

И вот теперь есть доступ к облачной упралялке SandBlast агентами:



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

URL Filtering


Название говорит само за себя. Теперь URL фильтрация будет доступна и на агентах. Вы можете фильтровать трафик даже удаленных пользователей, как-будто они сидят в офисе. На текущий момент доступно несколько основных категорий для URL фильтрации:

  • Security
  • Productivity loss
  • Legal Liability & Regulatory compliance
  • Bandwidth consumption
  • General use

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

  • Аддон для браузера доступен только для Google Chrome. Поддержка других браузеров ожидается в ближайшее время.
  • Функция URL Filtering пока доступна только через облачный менеджмент. Вот так выглядит интерфейс:



Также стоит отметить, что появилась новая функция Anti-Credential Theft Pass-the-Hash attack Protection. Но о ней мы подробно расскажем наверно уже в рамках будущего курса.

Новые платформы для SandBlast Agent


SandBlast теперь нативно поддерживает работу как в persistent VDI, так и в non-persistent. Но важнее другое. Наконец появилась бета версия SandBlast Agent-а для Linux систем. Вот небольшая демонстрация, где за одно показывается интеграция с Check Point Threat Hunting:



На мой взгляд, управление политиками стало удобнее. Логи с SandBlast Agent-ов теперь тоже в более привычном виде.

Как вы наверно поняли, управление через веб пока доступно только для облачной платформы. Однако, оно станет доступно и для локальных устройств в версии Gaia R81, которую должны анонсировать в первом квартале 21-го года.

Ключевые улучшения агента


Вот несколько ключевых изменений и улучшений SandBlast Agent-а версии E83.10:

Threat prevention
  • Behavioral Guard now protects against the Pass The Hash technique for credential theft. Credential Dumping is new, as of the previous release.
  • Fixes an issue where Anti-Ransomware does not detect a potential attack when the user is not logged in.
  • Fixes Anti-Ransomware false positives due to user profile deletions.
  • Fixes multiple rare cases of false positives in Anti-Ransomware.
  • Fixes an issue where out of memory errors occur when the log lists a very large number of backups.
  • When you disable Anti-Ransomware, the backup driver no longer operates.
  • Improves performance as Forensics now stores fewer named objects, such as mutexes and events.
  • Improves the performance of Forensics, Behavioral Guard and Threat Hunting with enhancements to our Registry Operation exclusion algorithms that reduce the number of recorded registry operations.
  • Resolves an issue where an Anti-Malware scheduled scan occurs, even if it is not in the policy.
  • Resolves an Anti-Malware icon scaling issue.
  • Resolves a possible issue where the Anti-Malware process crashes as it shuts down.


Data and Access Control
  • Resolves client network issues after a Firewall driver uninstallation failure.
  • Resolves a rare issue where an added Firewall blade gets stuck in the Initializing state.
  • Resolves a possible upgrade issue where the Firewall blade does not start due to a WatchDog failure.
  • Resolves a rare issue where the Firewall policy is Not Set in the client after the policy download from the server.
  • Resolves a possible issue where the Disk Encryption process crashes during shutdown.
  • Resolves a removable media icon blink issue for an encrypted partition when Media Scan is enabled.
  • Improves the work with non-UTF-8 applications. Users can toggle UTF-8 support.
  • Fixes active File Transfer Protocol (FTP) traffic blocks on a standalone VPN client with Firewall.
  • Includes stability and quality fixes. Supports all the features of previous releases.


Installation & Infrastructure
  • Resolves a possible issue where uninstalling the Endpoint removes components that are necessary for other applications.
  • Resolves a possible issue where the uninstall fails after the user turns off Network Protection.
  • Resolves a possible issue where the Endpoint Security Client does not run correctly after an operating system upgrade.
  • Resolves a rare issue where the client uninstall fails with Error 1921: Service Check Point Endpoint Agent (CPDA) could not be stopped.
  • Resolves a rare issue where an upgrade that uses Dynamic Package continuously loops after a download fails to resume.
  • The pre-boot language selection choice is now correct after a language update in Windows.
  • Fixes an incompatibility issue with Sophos Antivirus, which could not install on a machine with Endpoint Security Client on it.
  • Resolves a rare User Interface (UI) issue where a malware resolution is not shown to a user.
  • Resolves a client LogViewer issue, where it only shows log records that match the latest log schema.
  • On the Endpoint Security Client screen, the Overview list now shows Anti-Bot and URL Filtering instead of Anti-Bot.
  • The client User Interface (UI) is no longer shown during manual upgrades.
  • Resolves URL infections report issues in the User Interface (UI) so that the infections records are not permanent in the client and server UIs.
  • Anti-Bot and URL Filtering policy now translates to all supported languages.
  • Improves the performance of the Endpoint Security core driver to reduce CPU consumption.



Вместо заключения


Уверен будет интересна статья про форензику, которую может предоставлять SandBlast Agent. Как уже было упомянуто, мы планируем публикацию новых обучающих материалов, поэтому следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Кроме того, в ближайшее время состоится несколько полезных вебинаров по Check Point:


Успейте зарегистрироваться!
Подробнее..

Сделай сам или как кастомизировать телефон Snom. Часть 1 цвета, шрифт, фон

23.06.2020 18:09:52 | Автор: admin
Многим из нас очень нравится, когда какая-либо вещь сделана под нас! Когда мы ощущаем некий уровень собственности, который нам позволяет выделяться на фоне серой массы. Одни и те же стулья, столы, компьютеры и т.д. Всё как у всех!

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

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

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

image

Прошивка меню наших телефонов построена на XML и позволяет вам производить гибкую кастомизацию UI следующих параметров (краткий список):

  • фоновое изображение
  • шрифт и цвет
  • иконки
  • язык
  • мелодии звонков
  • назначение клавиш
  • и многое другое

В этой, 1й части нашей статьи, мы расскажем о том, как можно изменить визуальное представление телефонна Snom. Поговрим о нескольких пунктах:

  1. Изменение цветовой гаммы
  2. Изменение шрифтов
  3. Загрузка фонового изображения
  4. Примеры тем


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


1. Изменение цветовой гаммы



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

Для того, чтобы было проще разобраться существует схема описания настройки цветов:



Цвета настраиваются с помощью RGB значений

Наименование


Допустимые значения


Значения по
умолчанию


Описание


titlebar_text_color


Группа из 4-х
чисел, каждое >=0 и <=255.


красный, зеленый, синий, альфа (значение альфа 255 означает полностью
видимый, а 0 полностью прозрачный).


515151255


Управляет цветом и прозрачностью текста в
строке заголовка, например, Дата, Время,
Название и др.


text_color


51 51 51
255


Управляет цветом и прозрачностью
основного текста, например, Меню, Режим ожидания и
всех остальных экранов основного текста.


subtext_color


123 124 126 255


Управляет цветом и прозрачностью
подтекста, например, Меню, Режим ожидание и всех
других подтекстовых экранов.


extratext_color


123 124 126
255


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


extratext2_color


123 124 126
255


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


titlebar_background_color


226 226 226
255


Управляет цветом и прозрачностью фона
строки заголовка


background_color


242 242 242
255


Управляет цветом и прозрачностью фона на
каждом экране.


fkey_background_color


242 242 242
255


Управляет цветом и прозрачностью
контекстно-зависимых кнопок.


fkey_pressed_background_color


61 133 198
255


Управляет цветом и прозрачностью фона
контекстно-зависимых клавиш при нажатии.


fkey_separator_color


182 183 184
255


Управляет цветом и прозрачностью
разделительных линий контекстно-зависимых кнопок


fkey_label_color


123 124 126
255


Управляет цветом и прозрачностью текста,
используемого в контекстно-зависимых кнопках


fkey_pressed_label_color


242 242 242
255


Управляет цветом и прозрачностью текста,
используемого в контекстно-зависимых кнопках при нажатии


selected_line_background_color


255 255 255
255


Управляет цветом и прозрачностью фона
выбранной линии, например, в Меню или любом экране с выбираемыми элементами


selected_line_indicator_color


61 133 198
255


Управляет цветом и прозрачностью
индикатора слева от выбранной линии, например, в Меню или любом экране с
выбранными элементами


selected_line_text_color


61 133 198
255


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


line_background_color


242 242 242
0


Управляет цветом и прозрачностью фона для
каждой строки Меню или пункта меню, или любого пункта списка.


line_separator_color


226 226 226
255


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


scrollbar_color


182 183 184
255


Управляет цветом и прозрачностью полосы
прокрутки, отображаемой на любом экране.


cursor_color


61 133 198
255


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


status_msgs_background_color


242 242 242
255


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


status_msgs_border_color


182 183 184
255


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


smartlabel_background_color


242 242 242
255


Управляет цветом и прозрачностью фона SmartLabel.


smartlabel_pressed_background_color


61 133 198
255


Управляет цветом и прозрачностью фона SmartLabel при нажатии функциональной клавиши.


smartlabel_separator_color


182 183 184
255


Управляет цветом и прозрачностью линии
разделителя между каждой функциональной клавишей SmartLabel.


smartlabel_label_color


123 124 126
255


Управляет цветом и прозрачностью текста,
используемого в SmartLabel.


smartlabel_pressed_label_color


242 242 242
255


Управляет цветом и прозрачностью текста,
используемого в SmartLabel, при нажатии функциональной клавиши.







Теперь, когда мы знаем где и что находится мы можем перейти в веб-интерфейс телефона в раздел Setup/Preferences, далее вторая закладка Appearance:



Здесь можно изменять значения, а если нажать на вопросительный знак, то вы попадете на страницу с описанием, где в том числе есть заметка, как указать данное значение, если использовать XML-файл для конфигурации. Например для нашей первой строки Text Color:



2. Изменение шрифтов



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

Чтобы заменить любой шрифт, необходимо создать tar-файл, содержащий новый шрифт, названный должно полностью совпадать со старым шрифтом, который будет заменен.

tar -cvf fonts.tar fontfile.ttf


Затем на этот tar-файл нужно дать ссылку в xml-файле, чтобы он правильно загружался при перезагрузке телефона.

<?xml version="1.0" encoding="utf-8" ?><settings> <uploads>  <file url="http://personeltest.ru/away/192.168.23.54:8080/fonts.tar" type="font" /> </uploads></settings>


Более подробно, какие шрифты предустановлены, можно найти у нас на wiki
Таким образом вы можете загрузить свой собственны шрифт в телефон.

3. Загрузка фонового изображения


На примере покажем, как загрузить правильно фон и какие настройки имеют значение.



Загрузить фоновое изображение можно через Веб-интерфейс Preferences Appearance:



В этом параметре должен быть установлен доступный URL-адрес изображения. Как только параметр будет изменен, фоновое изображение будет заменено.

Или вы можете изменить эту настройку с помощью автопровижинга, добавив тег <custom_bg_image_url> с действительным значением в ваш xml-файл.

Если этот параметр пустой или URL-адрес изображения неверны, то будет использоваться фоновое изображение телефона по умолчанию.

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



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

Начиная с версии прошивки 10.1.33.33, цветовая прозрачность фона автоматически адаптируется к отображаемому на телефоне фоновому изображению. Однако она не будет полностью прозрачной. Для достижения полной прозрачности настройка <background_color> все равно должна иметь альфа-значение 0.

Для правильного отображения фонового изображения его необходимо сохранить в формате png, jpg, gif, bmp или tga. Мы настоятельно рекомендуем использовать файлы .png и оптимизировать их с помощью "optipng", чтобы уменьшить размер файла и повысить производительность.

Размер изображения в завсимости от модели:

Модель Разрешение
D375/ D385/ D785 480 x 272
D335/ D735/ D765 320 x 240
D717 426 x 240


4. Пример конфигурации тем



1. Dark Theme:



Посмотреть
<?xml version="1.0" encoding="utf-8"?><settings><phone-settings>  <!-- When the background image is set, it automatically applies alpha changes to all elements.   Therefore it has to be listed at the beginning, so that all styles afterwards correctly apply-->  <custom_bg_image_url perm=""></custom_bg_image_url>  <!-- Background color is set to be not transparent because no background image is configured -->  <background_color perm="">43 49 56 255</background_color>  <titlebar_text_color perm="">242 242 242 255</titlebar_text_color>  <titlebar_background_color perm="">43 49 56 255</titlebar_background_color>  <text_color perm="">242 242 242 255</text_color>  <subtext_color perm="">224 224 224 255</subtext_color>  <extratext_color perm="">158 158 158 255</extratext_color>  <extratext2_color perm="">158 158 158 255</extratext2_color>  <fkey_background_color perm="">43 49 56 255</fkey_background_color>  <fkey_pressed_background_color perm="">61 133 198 255</fkey_pressed_background_color>  <fkey_separator_color perm="">70 90 120 255</fkey_separator_color>  <fkey_label_color perm="">224 224 224 255</fkey_label_color>  <fkey_pressed_label_color perm="">242 242 242 255</fkey_pressed_label_color>  <line_background_color perm="">242 242 242 0</line_background_color>  <selected_line_background_color perm="">50 60 80 255</selected_line_background_color>  <selected_line_indicator_color perm="">61 133 198 255</selected_line_indicator_color>  <selected_line_text_color perm="">61 133 198 255</selected_line_text_color>  <line_separator_color perm="">70 90 120 255</line_separator_color>  <scrollbar_color perm="">70 90 120 255</scrollbar_color>  <cursor_color perm="">61 133 198 255</cursor_color>  <status_msgs_background_color perm="">43 49 56 255</status_msgs_background_color>  <status_msgs_border_color perm="">70 90 120 255</status_msgs_border_color>  <!-- Settings for SmartLabel -->  <smartlabel_background_color perm="">43 49 56 255</smartlabel_background_color>  <smartlabel_pressed_background_color perm="">61 133 198 255</smartlabel_pressed_background_color>  <smartlabel_separator_color perm="">70 90 120 255</smartlabel_separator_color>  <smartlabel_label_color perm="">224 224 224 255</smartlabel_label_color>  <smartlabel_pressed_label_color perm="">242 242 242 255</smartlabel_pressed_label_color></phone-settings></settings>



2. Colorful Theme:



Посмотреть
<?xml version="1.0" encoding="utf-8"?><settings><phone-settings>  <!-- When the background image is set, it automatically applies alpha changes to all elements.  Therefore it has to be configured at the beginning so that all styles afterwards correctly apply-->  <custom_bg_image_url perm="">http://192.168.0.1/background.png</custom_bg_image_url>  <!-- Background color has to be transparent because a background image is configured -->  <background_color perm="">0 0 0 0</background_color>  <titlebar_text_color perm="">242 242 242 255</titlebar_text_color>  <titlebar_background_color perm="">43 49 56 40</titlebar_background_color>  <text_color perm="">242 242 242 255</text_color>  <subtext_color perm="">224 224 224 255</subtext_color>  <extratext_color perm="">224 224 224 255</extratext_color>  <extratext2_color perm="">224 224 224 255</extratext2_color>  <fkey_background_color perm="">43 49 56 40</fkey_background_color>  <fkey_pressed_background_color perm="">43 49 56 140</fkey_pressed_background_color>  <fkey_separator_color perm="">0 0 0 0</fkey_separator_color>  <fkey_label_color perm="">224 224 224 255</fkey_label_color>  <fkey_pressed_label_color perm="">224 224 224 255</fkey_pressed_label_color>  <line_background_color perm="">0 0 0 0</line_background_color>  <selected_line_background_color perm="">43 49 56 40</selected_line_background_color>  <selected_line_indicator_color perm="">61 133 198 255</selected_line_indicator_color>  <selected_line_text_color perm="">61 133 198 255</selected_line_text_color>  <line_separator_color perm="">0 0 0 0</line_separator_color>  <scrollbar_color perm="">61 133 198 255</scrollbar_color>  <cursor_color perm="">61 133 198 255</cursor_color>  <status_msgs_background_color perm="">61 133 198 255</status_msgs_background_color>  <status_msgs_border_color perm="">61 133 198 255</status_msgs_border_color>  <!-- Settings for SmartLabel -->  <smartlabel_background_color perm="">43 49 56 40</smartlabel_background_color>  <smartlabel_pressed_background_color perm="">43 49 56 140</smartlabel_pressed_background_color>  <smartlabel_separator_color perm="">0 0 0 0</smartlabel_separator_color>  <smartlabel_label_color perm="">242 242 242 255</smartlabel_label_color>  <smartlabel_pressed_label_color perm="">242 242 242 255</smartlabel_pressed_label_color></phone-settings></settings>



Надеемся, эта тема поможет разобраться с вопросом ручной кастомизации.

Продолжение следует
Подробнее..

Настраиваем экспорт IPFIX на VMware vSphere Distributed Switch (VDS) и последующий мониторинг трафика в Solarwinds

26.06.2020 08:09:31 | Автор: admin
Привет, Хабр! В начале июля Solarwinds анонсировал релиз новой версии платформы Orion Solarwinds 2020.2. Одно из нововведений в модуле Network Traffic Analyzer (NTA) поддержка распознавания IPFIX-трафика от VMware VDS.



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

Для корректного распознавания трафика от VDS, сначала нужно настроить подключение через интерфейс vCenter, а уже потом анализ трафика и отображение точек обмена трафиком, получаемого от гипервизоров. При желании, коммутатор может быть настроен на получение всех записей IPFIX с одного IP-адреса, привязанного к VDS, но, в большинстве случаев, более информативно видеть данные, извлекаемые из трафика, полученного от каждого гипервизора. Трафик, который приходит, будет представлять соединения от или к виртуальным машинам, расположенных на гипервизорах.

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

Настройка трафика от VDS


Начнём с добавления экземпляра vCenter в Solarwinds. После этого NTA будет обладать информацией о конфигурации платформы виртуализации.

Перейдите в меню Manage Nodes, далее Settings и выберите Add Node. После этого нужно ввести IP-адрес или полное доменное имя экземпляра vCenter и выбрать VMware, Hyper-V, or Nutanix entities в качестве метода опроса.

image

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

image

В течении некоторого времени будет выполняться начальный опрос экземпляра vCenter, обычно 10-20 минут. Нужно дождаться завершения, а уже потом включить экспорт IPFIX на VDS.

После настройки мониторинга vCenter и получения инвентарных данных по конфигурации платформы виртуализации, включим на коммутаторе экспорт записей IPFIX. Самый быстрый способ сделать это через клиент vSphere. Перейдем на вкладку Networking, выберем VDS и на вкладке Configure найдём текущие настройки для NetFlow. VMware использует термин NetFlow для обозначения экспорта потока, но фактический протокол, который используется IPFIX.

image

Чтобы включить экспорт потока, выберите Settings в меню Actions вверху и перейдите к Edit NetFlow.

image

В этом диалоговом окне введите IP-адрес коллектора, который по совместительству является экземпляром Orion. По умолчанию обычно используется порт 2055. Рекомендуем оставить поле Switch IP Address пустым, что приведет к получению потоковых записей, получаемых именно от гипервизоров. Это даст гибкость при дальнейшей фильтрации потока данных от гипервизоров.

Оставьте поле Process internal flows only отключенным, что позволит видеть все коммуникации: как внутренние, так и внешние.

Как только включите экспорт потока для VDS, нужно будет включить его также и для распределенных порт-групп, от которых хотите получать данные. Самый простой способ сделать это щелкнуть правой кнопкой мыши на панели навигации VDS и выбрать Distributed Port Group, а затем Manage Distributed Port Groups.

image

image

Откроется диалоговое окно, в котором нужно установить флажок Monitoring и нажать Next.

На следующем шаге можете выбрать определённые или все группы портов.

image

На следующем шаге переключите NetFlow на Enabled.

image

Когда на VDS и распределенных порт-группах включен экспорт потока, вы увидите, что записи потоков для гипервизоров начинают поступать в экземпляр NTA.

image

Гипервизоры можно увидеть в списке источников данных потока на странице Manage Flow Sources в NTA. Переключитесь на Nodes.

image

Результаты настройки вы можете увидеть на демо-стенде. Обратите внимание на возможность провалиться на уровень узла, протокола взаимодействия и т.д.



Интеграция с другими модулями Solarwinds в одном интерфейсе, позволяет проводить расследования в различных разрезах: посмотреть какие пользователи входили на виртуальную машину, производительность сервера (посмотреть демо), и приложений на нём, посмотреть связанные сетевые устройства и много чего ещё. Например, если в вашей сетевой инфраструктуре используется протокол NBAR2, Solarwinds NTA может успешно распознавать трафик от Zoom, Teams или Webex.

Основная цель статьи показать простоту настройки мониторинга в Solarwinds и полноту собираемых данных. В Solarwinds есть шанс увидеть полную картину происходящего. Если хотите презентацию решения или проверить всё у себя оставьте заявку в форме обратной связи или позвоните.

На Хабре у нас также есть статья о бесплатных решениях Solarwinds.

Подписывайтесь на нашу группу в Фейсбуке.
Подробнее..

Интеграция Open vSwitch с Р-виртуализацией

01.07.2020 10:24:00 | Автор: admin

Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.


Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.



Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.


Железо


Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.


Развертывание РП


Краткая инструкция по установке:


  • 1. Устанавливаем первую ноду, в анаконде назначаем IP хосту и из этой же подсети виртуальный IP для управления Р-виртуализации, и IP для управления Р-хранилищем. Дисков как минимум должно быть 3, один для хоста (ОС/гипервизор) в моем случае HDD, второй и третий диск уже настроим через управление Р-хранилищем, где один SSD под кэш и другой под чанк сервер. На втором интерфейсе назначаем IP из другой подсети для сети хранения без шлюза.
  • 2. После установки заходим через браузер хром по IP адресу управления Р-хранилищем, далее выбираем раздел серверы и нажимаем на вопросик с прямоугольником, и выбираем раздел сеть, в нем назначаем роли для интерфейса с адресом подсети управления(роли ssh, управление, web cp) и для интерфейса с подсетью для хранения назначаем роли (ssh, хранилище).
  • 3. Далее нажимаем создать кластер вводим его имя автоматом должен подключится интерфейс с ролью хранения и выбрать подробные настройки, убедится что система правильно распределила роли на дисках, один должен быть системный, другой служба метаданных плюс кэш если это SSD и далее третий диск HDD в роли хранения (чанк сервер).
  • 4. Параллельно с установкой первой ноды можно устанавливать две последующие, назначить каждой по два IP адреса один для подсети управления Р-виртуализации, на втором интерфейсе из подсети хранения. Если оставить поля регистрации на сервере управления Р-виртуализации и управления Р-хранилище пустыми то, можно продолжить установку без указания IP адресов управления, а регистрацию выполнить потом.
  • 5. После того как последующие ноды установлены пройти по IP адресу этих хостов через ssh в cli и выполнить регистрацию, где IP это адрес управления Р-хранилищем и токен можно скопировать с веб управления р-хранилищем при нажатии добавить ноду.
  • 6. После того как обе ноды появятся в веб управлениии Р-хранилище выполнить те же действия что в пункте 2-3 только вместо создания кластера выбрать присоединить.
  • 7. Далее после создания кластера появится пункт сервисы в нем создать хранилище датастор в зависимости наличия дисков и узлов можно делать реплику 2 или 3 и т.д. если узла 3 то, реплика 2, остальное все по умолчанию.
  • 8. Далее проходим по IP адресу управления Р-виртуализации нажимаем добавить если физ. сервер если не добавлен и добавляем остальные, далее устанавливаем триал лицензию, далее в настройках хоста выполнить Изменение настроек хоста для виртуальных сред выбрать вместо локальной папки по умолчанию можно для всех пунктов(для первого раза лучше так) выбираем наш датастор который создавали в Р-хранилище и ставим галочку применить на все хосты.
  • 9. После это мигрируем vstorage-ui и va-nm на любой другой хост, время может занять некоторое потому что это миграция с локальных носителей на кластерные.
  • 10. После этого открываем ssh консоли всех трех узлов и вводим команду включения HA на каждом узле, где IP адрес сети хранения, после этого необходимо проверить командой #shaman stat
  • 11. После этого можно приступать к созданию ВМ, где я в качестве гостевой установил CentOS 7.

команда регистрации ноды к выше описанному пункту 5:


#/usr/libexec/vstorage-ui-agent/bin/register-storage-node.sh -m 10.43.10.14 -t ec234873

комнда включения HA к пункту 10:


#hastart -c имя кластера -n 192.168.10.0/24 

и проверка HA, где вывод должен быть примерно такой:


[root@n3 ~]# shaman statCluster 'rptest'Nodes: 3Resources: 7    NODE_IP           STATUS     ROLES                RESOURCES    192.168.10.10     Active     VM:QEMU,CT:VZ7       0 CT, 0 VM    192.168.10.11     Active   VM:QEMU,CT:VZ7       0 CT, 0 VM*M 192.168.10.12     Active     VM:QEMU,CT:VZ7       2 CT, 0 VM

Установка и настройка OVS


На первой и третей ноде кластера были установлены OVS следующей командой:


#yum install openvswitch 

После установки можно проверить командой


#ovs-vsctl show 

Вывод будет примерно следующий:


[root@node1 ~]# ovs-vsctl show180c5636-2d3d-4e08-9c95-fe5e47f1e5faovs_version: "2.0.0"[root@node1 ~]#

Далее необходимо создать мост виртуального коммутатора на который и будем вешать порты, интерфейсы или другие мосты.


# ovs-vsctl add-br ovsbr0 

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


#ovs-vsctl add-br brlv140 ovsbr0 140 

Тег при этом может быть не привязан к какому-то реальному тегу с физического порта, это только в рамках виртуального коммутатора.
Далее назначаем его ВМ к виртуальной сети, где предварительно создаем xml файл:


<network> <name>ovsvl</name> <forward mode='bridge'/> <bridge name='brlv140'/> <vlan>  <tag id='140'/></vlan><virtualport type='openvswitch'/></network>

К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:


#virsh net-list --all 

Для добавления нашей сети:


#virsh net-define ovsvl.xml 

Далее необходимо ее запустить/активировать


#virsh net-start ovsvl

И прописать в автостарт


#virsh net-autostart ovsvl

Далее необходимо добавить эту сеть к ВМ


#virsh edit имяВМ 

Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):


<interface type='bridge'>      <mac address='00:1c:42:c6:80:06'/>

  <vlan>    <tag id='140'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='5a70be5b-5576-4734-9f61-61cdfc4a884a'/>  </virtualport>  <target dev='vme001c42c68006'/>  <model type='virtio'/>  <boot order='2'/>  <alias name='net0'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></interface>


Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:


#prlctl stop имя ВМ

#prlctl start имя ВМ

Для проверки можно ввести команду:


#virsh dumpxml имяВМ | grep имясети 

После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.12 

где IP адрес это адрес той ноды на которой произведены такие же настройки как показано выше. Прямая связь между этими адресами может быть, как через роутеры, так и через VPN, и из разных подсетей, главное, чтобы между ними был настроен маршрут. Но еще главнее, чтобы интерфейс физического порта на котором назначен это адрес, был настроен MTU больше чем 1500 для пропускания пакетов с большим размером, так как vxlan добавляет свои данные, заголовок в несколько байт, но я не стал заморачиваться считать все байты и просто назначил 2000.
Например:


#ip link set mtu 2000 dev ens3f0

сам мост зависящий от этого интерфейса тоже должен быть с mtu2000, но он может не сразу его наследовать и возможно понадобиться его перезапустить.


На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.10

Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:


#tcpdump i ens3f0 | grep 4789``` то можно увидеть пакеты с vxlan или c тегами vlan ```bash#tcpdump -ee -vvv -i ens3f0 | grep vlan

Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:


 <network><name>ovsvl2</name><forward mode='bridge'/><bridge name='ovsbr0'/><virtualport type='openvswitch'/><portgroup name='vlan-120'>    <vlan>      <tag id='120'/>    </vlan>  </portgroup></network>

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


<interface type='bridge'>      <mac address='00:1c:42:c8:f1:cd'/>

  <vlan>    <tag id='120'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='ef717aa4-23b3-4fbe-82bb-193033f933b1'/>  </virtualport>  <target dev='vme001c42c8f1cd'/>  <model type='virtio'/>  <boot order='3'/>  <alias name='net1'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/></interface>


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


#ovs-vsctl set port ens3f4 trunks=120,130#ovs-vsctl add-port ovsbr0 ens3f4  

И можно добавить порт с тегом 120 для ВМ:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

На стороне другого виртуального коммутатора на другой ноде другого кластера, где нет транка от физического коммутатора добавить точно также этот порт то есть:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

Плюс добавить сеть как описано выше.


Пример вывода настроек OVS и ВМ



Вывод команды #ovs-vsctl show на первой ноде. Порты и интерфейсы с именем начинающимся с vme являются виртуальными интерфейсами ВМ, которые автоматически попадают в конфиг при запуске ВМ подключенному к OVS.



Вывод команды #ovs-vsctl show на третей ноде



Вывод команды virsh net-list содержит 4 вида сети, где Bridged и Host-Only это стандартные классические варианты от Р-виртуализации по дефолту, а ovsvl и ovsvl2 это то, что мы добавили по инструкции выше. Ovsvl получается для варианта с тегированным мостом tag 140 поверх моста OVS, а ovsvl2 это вариант с группой портов portgroup состоящей из одного порта с tag 120. Portgroup очень удобен и в него можно добавлять больше одного порта используя только одну сеть вместо большого количества сетей в классическом варианте Р-виртуализации с мостами под которыми разные VLAN интерфейсы. Далее вывод команды #virsh net-dumpxml ovsvl и ovsvl2 показывающие содержимое настроек этих сетей.



Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:


 #virsh dumpxml имяВМ

Тесты


При тестировании OVS была проверена совместимость с запущенным networkmanager(NM), выше описанные сценарии работают нормально, но при автозапуске службы NM может выдавать сообщения по интерфейсам виртуального коммутатора, которыми не может управлять, NM можно выключить, но на функциональность сети это не влияет.


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


Также были успешно проверены живые миграции ВМ с сетями от OVS, если на каждой ноде имеется экземпляр сети вместе с OVS то, проблем с миграцией нет, так же как и в стандартной конфигурации кластера Р-виртуализации с дополнительными сетями для ВМ.



На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.


Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.


По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.


Описание сценариев


Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.



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



Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.


Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке



В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.


Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища. Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.


Как работает классический br0 я описывать не буду, ovsbr0 работает со IP стеком ОС, который на этой картинке определен для br0, то есть экземпляр виртуального коммутатора в виде ovsbr0 работает в данном случае через br0. Другими словами статический IP адрес ноды назначен на классический br0 и весь трафик, который направлен в эту подсеть с виртуального коммутатора проходит через br0, так же как это работает для всех приложений этой ноды. С точки зрения настройки в этом случае никаких cli назначений на br0 со стороны виртуального коммутатора не производилось кроме настройки vxlan интерфейса с option, соответственно если у ноды есть второй классический br1 c другим IP адресом и подсетью висящий на другом физическом порту например eth2 или eth3 то, с виртуального коммутатора за счет стека ОС и его таблицы mac-ов можно направить пакеты в эти подсети назначив какой либо порт виртуального коммутатора в эту подсеть и подключить к ВМ, адрес подсети будет непосредственно назначаться внутри ВМ или в ее настройках.


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



У виртуального коммутатора есть своя таблица маков.


У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.


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


Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее VxLAN тоннель коммутатор воспринимает как простой транковый порт.


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


Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.


Заключение


При выполнении настроек OVS понравилась простота, удобносто, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.


Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
1)https://www.sidorenko.io/post/2018/11/openstack-networking-open-vswitch-and-vxlan-introduction/
2) https://blog.remibergsma.com/2015/03/26/connecting-two-open-vswitches-to-create-a-l2-connection/
3)http://mx54.ru/nastrojka-setevyx-interfejsov-v-kvm-dlya-virtualnyx-mashin/
4) https://kamaok.org.ua/?p=2677
5)https://kashyapc.fedorapeople.org/virt/add-network-card-in-guest.txt
6)https://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/#.XuZ960UzaM_

Подробнее..

Обзор IP телефона Snom D725 или когда нужно много физических кнопок

01.07.2020 10:24:00 | Автор: admin
Здравствуйте дорогие читатели!
Мы продолжаем обзор модельного ряда IP-телефонов Snom и сегодня подготовили для вас обзор на телефон с наибольшим количеством физических функциональных клавиш из нашей линейки модель Snom D725.

image

Распаковка и комплектация


Как и всегда в наших обзорах, рассмотрим комплектацию и упаковку аппарата. Коробка достаточно компактна, на ней присутствует информация о модели и версии ПО телефона. Комплектация включает в себя:
  • Телефонный аппарат
  • Краткое руководство пользователя
  • Подставку
  • Ethernet-кабель категории 5E
  • Трубку и витой шнур для ее подключения


image

Дизайн


Рассмотрим телефон поближе. Основная особенность аппарата большое количество BLF-клавиш, их здесь 18. Большая часть современных телефонов использует несколько страниц экрана для мониторинга состояния столь большого количества абонентов, но, давайте будем честны, мало кто в этом случае использует все страницы из-за необходимости перелистывания, а в данном случае все абоненты всегда на виду каждый на своей клавише. Минусом такого устройства является необходимость вручную подписывать название клавиш, зато пользователь телефона однозначно запомнит расположение номеров абонентов на этих самых клавишах и сможет найти нужную ему кнопку очень быстро.

image

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

image

Экран на данном аппарате черно-белый, с крупным шрифтом и яркой подсветкой. Под экраном размещены четыре подэкранные функциональные клавиши, чуть ниже клавиши навигации. Джойстик на этом телефоне выполнен в виде круглой клавиши с четырьмя направлениями нажатия, слева и справа от него находятся кнопки подтверждения и отмены. Справа от последней, находится клавиша записи. Клавиши этого блока расположены достаточно разряжено, для удобства управления телефоном.
Чуть ниже находятся уже упомянутые восемнадцать BLF-клавиш. Они занимают центральную часть лицевой панели аппарата и расположены так, чтобы постоянно быть в поле зрения пользователя на виду. Так сотрудник всегда будет видеть состояние важных для него абонентов и, при необходимости сможет перевести или перехватить важный звонок.

image

Разъемы телефона находятся на его задней панели. Здесь расположились: 4-х пиновый разъем микролифта EHS, гигабитные порты PC и NET, разъем блока питания, порты трубки и гарнитуры и USB-порт. Доступ к большей части из них осуществляется снизу под подставкой.
Сама по себе подставка двухпозиционная, в зависимости от стороны крепления к телефону она обеспечивает углы наклона корпуса в 46 или 28 градусов, позволяя пользователю расположить корпус телефона удобно для своего зрения.

Программное обеспечение и настройка


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

Функционал и эксплуатация


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

image

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

image

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

Аксессуары


Как уже было сказано выше, на телефоне присутствует USB-разъем. Он используется для подключения USB-гарнитуры, флеш-накопителя, DECT донгла A230, Wi-Fi-модуля A210, а также панели расширения D7. Обратим внимание на последние.
Панель расширения D7 заметно увеличит и без того не малое количество BLF-клавиш, доступных для настойки на телефоне. Каждая из панелей предлагает пользователю еще 18 дополнительных клавиш, а всего к одному аппарату можно подключить до 3-х панелей, добавив к клавишам телефона еще 54 клавиши.
image
DECT-донгл A230 позволяет подключить к аппарату DECT-гарнитуру, увеличив мобильность сотрудника, либо же использовать внешний динамик Snom C52 SP, что позволяет использовать аппарат в большом кабинете или небольшой переговорной комнате.
Wi-Fi-модуль A210 используется для подключения к беспроводным сетям Wi-Fi. Модуль работает и с сетями 2.4 Ггц, и 5 Ггц, что позволяет подключать телефон к современным сетям связи компании.

Подведем итог


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

Кто внедряет IPv6 от компаний до целых стран

06.07.2020 20:09:26 | Автор: admin
Ранее мы говорили о том, что переход может занять еще десять лет. Сегодня продолжим тему и расскажем, кто внедряет IPv6 и где решают этот вопрос на законодательном уровне.


/ Unsplash / Clem Onojeghuo

Телекомы, провайдеры и ИТ-компании


Официальный запуск шестой версии протокола состоялся еще восемь лет назад. Практически сразу его начали использовать операторы связи и интернет-провайдеры австралийский Internode, нидерландский XS4ALL, немецкий Deutsche Telekom, а также американские AT&T и Comcast. У последних доля IPv6-трафика на сегодняшний день превышает 60%, а у Deutsche Telekom 35%.

Немного позже к телекоммуникационным компаниям присоединились владельцы сайтов. Сейчас работу с IPv6 поддерживает около 20% ресурсов из списка Alexa 500. Если говорить обо всех сайтах в сети, то эта цифра будет меньше 16,3%. На IPv6 переходят и ИТ-компании например, Google и Facebook. С 2018 года более половины американских пользователей соцсети работает с новым протоколом. IPv6-трафик Facebook растет и в странах Азии Вьетнаме и Тайване.

Свежие материалы из нашего блога на Хабре:


Внедряют IPv6 также правительственные и исследовательские организации. Еще в 2010 году CERN начали развертывать виртуальные машины, поддерживающие новый протокол, их общее количество превысило 130 тыс. Хотя объем передаваемых данных остается небольшим в день через сети IPv6 в организации проходит 2,5 Гбайта трафика.

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

Подробнее о ситуации мы рассказывали в одном из предыдущих материалов.

Что с регулированием


Протокол нового поколения продвигают не только ИТ-компании и телекомы, но и правительства отдельных государств. Так, Беларусь стала первой страной в мире, закрепившей поддержку IPv6 на законодательном уровне. С начала года работу с новым протоколом обязаны начать все интернет-провайдеры. Пока что с IPv6 работает около 15% пользователей, хотя периодически эта цифра увеличивается до 30%. Можно ожидать, что эти значения будут только расти.


/ Unsplash / Christopher Burns

Подобные инициативы есть и в США. В начале марта Административно-бюджетное управление страны (OMB) опубликовало документ, согласно которому не менее 80% ресурсов госорганизаций должны начать поддерживать IPv6 до конца 2025 года. К слову, внедрением нового протокола американское правительство занимается еще с 2005-го. Однако процесс идет медленно, так как министерства ссылаются на проблемы с безопасностью и потенциальные перебои в работе госуслуг. Документ 2020 года может переломить ситуацию и предопределить рост числа сайтов, использующих новый протокол.

Чтение по теме из корпоративного блога VAS Experts:

Подробнее..

Перевод Учебник по симулятору сети ns-3. Заключительные главы 8, 9

23.06.2020 06:21:42 | Автор: admin
image
[главы 1,2]
[глава 3]
[глава 4]
[глава 5]
[глава 6]
[глава 7]

Глава 8 Сбор информации
8.1 Мотивация
8.2 Пример кода
8.3 GnuplotHelper
8.4 Поддерживаемые типы трасс
8.5 FileHelper
8.6 Итоги
Глава 9 Заключение
9.1 На будущее
9.2 Завершение

Глава 8Сбор информации


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

8.1Мотивация


Одной из основных целей запуска симуляции является генерация выходных данных, либо для исследовательских целей, либо просто для изучения системы. В предыдущей главе мы представили подсистему трассировки и примерsixth.cc, который генерировал файлы PCAP или ASCII трассировок. Эти трассы ценны для анализа данных с использованием различных внешних инструментов и для многих пользователей такие выходные данные предпочтительны с точки зрения сбора данных (для анализа с помощью внешних инструментов).

Тем не менее, существуют варианты использования не только для генерации файла трассировки, они включат следующие:

  • генерация данных, которые плохо отображаются в PCAP или ASCII трассировки, данные которые не представлены в виде пакетов (например, переходы машины состояний протокола);
  • большие симуляции, для которых требования к диску по вводу/выводу во время генерации файлов трассировки являются непомерными или громоздкими;
  • необходимость сокращения или вычисления данных в режиме онлайн во время моделирования. Хороший пример этого определение условия завершения симуляции, чтобы остановить её при получении необходимого количества данных для формирования достаточно узкого доверительного интервала вокруг оценки некоторого параметра.

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

8.2Пример кода


Учебный примерexamples/tutorial/sevenh.ccнапоминает примерsixth.cc, который мы ранее проработали, за исключением нескольких изменений. Во-первых, в него было добавлено переключение на поддержку IPv6 параметром командной строки:
CommandLine cmd;cmd.AddValue ("useIpv6", "Use Ipv6", useV6);cmd.Parse (argc, argv);

Если пользователь указывает опциюuseIpv6, программа будет работать с использованием IPv6 вместо IPv4. Во всех программахns3, которые поддерживают объектCommandLine, доступна опция справки. Как показано выше, она может быть вызвана следующим образом (обратите внимание на использование двойных кавычек):
./waf --run "seventh --help"

который выдаст:
ns3-dev-seventh-debug [Program Arguments] [General Arguments]Program Arguments:--useIpv6: Use Ipv6 [false]General Arguments:--PrintGlobals: Print the list of globals.--PrintGroups: Print the list of groups.--PrintGroup=[group]: Print all TypeIds of group.--PrintTypeIds: Print all TypeIds.--PrintAttributes=[typeid]: Print all attributes of typeid.--PrintHelp: Print this help message.

Режим по умолчанию (использование IPv4, посколькуuseIpv6имеет значениеfalse) можно изменить, переключив логическое значение следующим образом:
./waf --run "seventh --useIpv6=1"

и посмотрите на сгенерированныйpcap, например, с помощьюtcpdump:
tcpdump -r seventh.pcap -nn -tt

Это было короткое отступление в поддержку IPv6 и командной строки, которая также была представлена ранее в этом руководстве. В качестве отдельного примера использования командной строки, пожалуйста, смотритеsrc/core/examples/command-line-example.cc. Теперь вернемся к сбору данных. В директорииexamples/tutorial/введем следующую команду:
diff -u sixth.cc sevenh.cc

и рассмотрим некоторые из новых строк этогоdiff:
+ std::string probeType;+ std::string tracePath;+ if (useV6 == false)+ {...+ probeType = "ns3::Ipv4PacketProbe";+ tracePath = "/NodeList/*/$ns3::Ipv4L3Protocol/Tx";+ }+ else+ {...+ probeType = "ns3::Ipv6PacketProbe";+ tracePath = "/NodeList/*/$ns3::Ipv6L3Protocol/Tx";+ }...+ // Use GnuplotHelper to plot the packet byte count over time+ GnuplotHelper plotHelper;++ // Configure the plot. The first argument is the file name prefix+ // for the output files generated. The second, third, and fourth+ // arguments are, respectively, the plot title, x-axis, and y-axis labels+ plotHelper.ConfigurePlot ("seventh-packet-byte-count",+ "Packet Byte Count vs. Time",+ "Time (Seconds)",+ "Packet Byte Count");++ // Specify the probe type, trace source path (in configuration namespace), and+ // probe output trace source ("OutputBytes") to plot. The fourth argument+ // specifies the name of the data series label on the plot. The last+ // argument formats the plot by specifying where the key should be placed.+ plotHelper.PlotProbe (probeType,+ tracePath,+ "OutputBytes",+ "Packet Byte Count",+ GnuplotAggregator::KEY_BELOW);++ // Use FileHelper to write out the packet byte count over time+ FileHelper fileHelper;++ // Configure the file to be written, and the formatting of output data.+ fileHelper.ConfigureFile ("seventh-packet-byte-count",+ FileAggregator::FORMATTED);++ // Set the labels for this formatted output file.+ fileHelper.Set2dFormat ("Time (Seconds) = %.3e\tPacket Byte Count = %.0f");++ // Specify the probe type, probe path (in configuration namespace), and+ // probe output trace source ("OutputBytes") to write.+ fileHelper.WriteProbe (probeType,+ tracePath,+ "OutputBytes");+Simulator::Stop (Seconds (20));Simulator::Run ();Simulator::Destroy ();

Внимательный читатель заметит, что при тестировании атрибута командной строки IPv6, описанного выше, файлsevenh.ccсоздал ряд новых выходных файлов:
seventh-packet-byte-count-0.txtseventh-packet-byte-count-1.txtseventh-packet-byte-count.datseventh-packet-byte-count.pltseventh-packet-byte-count.pngseventh-packet-byte-count.sh

Они были созданы дополнительными объявлениями, представленными выше. В частности,GnuplotHelperиFileHelper.

Эти данные были получены путем подключения к источникам трассировкиns3компонентов сбора и упорядочения данных для форматированногоgnuplotи форматированного текстового файлов. В следующих разделах мы рассмотрим каждый из них.

8.3GnuplotHelper


GnuplotHelper- это вспомогательный объектns3, предназначенный для создания графиковgnuplotдля общих случаев с минимальным, по возможности, количеством операторов.

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

Давайте посмотрим на вывод этого помощника:
seventh-packet-byte-count.datseventh-packet-byte-count.pltseventh-packet-byte-count.sh

Первый это файл данныхgnuplotс серией меток времени, разделенных пробелами, и счетчиками байтов пакетов. Мы рассмотрим ниже как этот конкретный вывод данных был настроен, но давайте продолжим с выходными файлами. Файлseventh-packet-byte-count.plt- это файл графикаgnuplot, который можно открыть вgnuplot. Читатели, которые понимают синтаксисgnuplot, могут увидеть, что он создаст отформатированный выходной файл PNG с именемseventh-packet-byte-count.png. Наконец, небольшой shell-сценарийsevenh-packet-byte-count.shзапускает этот файл графика черезgnuplotдля получения желаемого PNG (который можно просмотреть в редакторе изображений), после команды:
sh seventh-packet-byte-count.sh

выдастseventh-packet-byte-count.png. Почему этот PNG не был сделан сразу? Ответ заключается в том, чтобы пользователь, если хочет, мог вручную настроить предоставленный файлplt, перед созданием PNG. Название PNG-изображения показывает, что этот график представляет собой Число байтов пакетов в зависимости от времени и что он отображает захваченные данные, соответствующие пути источника трассировки:
/NodeList/*/$ns3::Ipv6L3Protocol/Tx

Обратите внимание на знак подстановки в пути трассировки. Итак, этот график захвата байтов пакетов, наблюдаемых на источнике трассировки объектаIpv6L3Protocol; в основном 596-байтовые сегменты TCP в одном направлении и 60-байтовые TCPackв другом (два источника трассировки узлов были сопоставлены этим источником трассировки).

Как это было настроено? Должны быть предоставлены несколько объявлений. Во-первых, объектGnuplotHelperдолжен быть объявлен и настроен:
+ // Use GnuplotHelper to plot the packet byte count over time+ GnuplotHelper plotHelper;++ // Configure the plot. The first argument is the file name prefix+ // for the output files generated. The second, third, and fourth+ // arguments are, respectively, the plot title, x-axis, and y-axis labels+ plotHelper.ConfigurePlot ("seventh-packet-byte-count",+ "Packet Byte Count vs. Time",+ "Time (Seconds)",+ "Packet Byte Count");

К этому моменту пустой график был настроен. Префикс имени файла первый аргумент, заголовок графика второй, подпись к оси X третий, а название оси Y четвертый аргумент.
Следующим шагом является настройка данных, вот где перехватывается источник трассировки. Во-первых, обратите внимание выше в программе мы объявили для дальнейшего использования несколько переменных:
+ std::string probeType;+ std::string tracePath;+ probeType = "ns3::Ipv6PacketProbe";+ tracePath = "/NodeList/*/$ns3::Ipv6L3Protocol/Tx";

Мы используем их здесь:
+ // Specify the probe type, trace source path (in configuration namespace), and+ // probe output trace source ("OutputBytes") to plot. The fourth argument+ // specifies the name of the data series label on the plot. The last+ // argument formats the plot by specifying where the key should be placed.+ plotHelper.PlotProbe (probeType,+ tracePath,+ "OutputBytes",+ "Packet Byte Count",+ GnuplotAggregator::KEY_BELOW);

Первые два аргумента это имя типа захвата и путь источника трассировки. Эти двое, вероятно, труднее всего определить, когда вы пытаетесь использовать эту структуру для построения других трасс. Здесь трасса захвата это трасса Tx источника классаIpv6L3Protocol. Когда мы исследуем реализацию этого класса (src/internet/model/ipv6-l3-protocol.cc) мы можем видеть:
.AddTraceSource ("Tx", "Send IPv6 packet to outgoing interface.",MakeTraceSourceAccessor (&Ipv6L3Protocol::m_txTrace))

Это говорит о том, что Tx это имя переменнойm_txTrace, которая имеет объявление:
/*** \brief Callback to trace TX (transmission) packets.*/TracedCallback<Ptr<const Packet>, Ptr<Ipv6>, uint32_t> m_txTrace;

Оказывается, что эта специфическая сигнатура источника трассировки поддерживается классомProbe(что нам и нужно) классаIpv6PacketProbe. Смотрите файлыsrc/internet/model/ipv6-packet-probe.{h, cc}.

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

Ipv6PacketProbeсам экспортирует некоторые источники трассировки, которые извлекают данные из исследуемого объектаPacket:
Ipv6PacketProbe::GetTypeId (){  static TypeId tid = TypeId ("ns3::Ipv6PacketProbe")  .SetParent<Probe> ()  .SetGroupName ("Stats")  .AddConstructor<Ipv6PacketProbe> ()  .AddTraceSource ( "Output",  "The packet plus its IPv6 object and interface that serve as the output for this probe",  MakeTraceSourceAccessor (&Ipv6PacketProbe::m_output))  .AddTraceSource ( "OutputBytes",  "The number of bytes in the packet",  MakeTraceSourceAccessor (&Ipv6PacketProbe::m_outputBytes));  return tid;}

Третий аргумент нашего оператораPlotProbeуказывает, что нас интересует количество байтов в этом пакете;

в частности, источник трассировки OutputBytesIpv6PacketProbe. Наконец, два последних аргумента объявления предоставляют условные обозначения для этой серии данных (Число байтов пакета) и необязательный оператор форматированияgnuplot(GnuplotAggregator :: KEY_BELOW), которым мы показываем, что хотим, чтобы легенда графика была вставлена ниже графика. Другие варианты включают NO_KEY, KEY_INSIDE и KEY_ABOVE.

8.4Поддерживаемые
типы трасс


На момент написания этой главы вProbesподдерживаются следующие трассируемые значения:

ТипTracedValue ТипProbe Файл
double DoubleProbe stats/model/double-probe.h
uint8_t Uinteger8Probe stats/model/uinteger-8-probe.h
uint16_t Uinteger16Probe stats/model/uinteger-16-probe.h
uint32_t Uinteger32Probe stats/model/uinteger-32-probe.h
bool BooleanProbe stats/model/uinteger-16-probe.h
ns3::Time TimeProbe stats/model/time-probe.h

и поддерживает следующие типыTraceSource:

Тип TracedSource Тип Probe Вывод Probe Файл
Ptr&ltconst Packet&gt PacketProbe байты network/utils/packet-probe.h
Ptr&lt const Packet&gt, Ptr&lt Ipv4&gt, uint32_t Ipv4PacketProbe байты internet/model/ipv4-packetprobe.h
Ptr&ltconst Packet&gt, Ptr&ltIpv6&gt, uint32_t Ipv6PacketProbe байты internet/model/ipv6-packetprobe.h
Ptr&ltconst Packet&gt, Ptr&ltIpv6&gt, uint32_t Ipv6PacketProbe байты internet/model/ipv6-packetprobe.h
Ptr&ltconst Packet&gt, const Address& ApplicationPacketProbe байты applications/model/applicationpacket-probe.h

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

8.5FileHelper


Класс FileHelper это всего лишь вариант предыдущего примераGnuplotHelper. Пример программы обеспечивает форматированный вывод тех же данных с метками времени, например:
Time (Seconds) = 9.312e+00 Packet Byte Count = 596Time (Seconds) = 9.312e+00 Packet Byte Count = 564

Предоставляются два файла, один для узла 0 и один для узла 1, как видно из имен файлов. Давайте посмотрим на код кусок за куском:
+ // Use FileHelper to write out the packet byte count over time+ FileHelper fileHelper;++ // Configure the file to be written, and the formatting of output data.+ fileHelper.ConfigureFile ("seventh-packet-byte-count",+ FileAggregator::FORMATTED);

Префикс вспомогательного файла является первым аргументом, а спецификатор формата следующим. Другие варианты форматирования включают SPACE_SEPARATED, COMMA_SEPARATED и TAB_SEPARATED. Пользователи могут изменить форматирование (если FORMATTED указывается) такой строкой формата:
++ // Set the labels for this formatted output file.+ fileHelper.Set2dFormat ("Time (Seconds) = %.3e\tPacket Byte Count = %.0f");

Наконец, должен быть подключен интересующий источник трассировки. Опять же, в этом примере используется переменныеprobeTypeиtracePath, подключается захват выхода источника трассировки OutputBytes:
++ // Specify the probe type, trace source path (in configuration namespace), and+ // probe output trace source ("OutputBytes") to write.+ fileHelper.WriteProbe (probeType,+ tracePath,+ "OutputBytes");+

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

8.6Итоги


Поддержка сбора данных появилась начиная сns3.18, была добавлена базовая поддержка вывода временных рядов. Описанный выше базовый шаблон может быть воспроизведен в рамках поддержки существующих захватов и источников трассировки. Дополнительные возможности, включая обработку статистики, будут добавлены в будущих релизах.

Глава 9Заключение


9.1На будущее


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

9.2Завершение


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

  • Руководство поns3
  • Документация библиотеки моделейns3
  • ns3 Doxygen(документация API)
  • ns3вики


Команда разработчиков ns3.
Подробнее..

Учебник по симулятору сети ns-3 теперь одним pdf-файлом

25.06.2020 16:23:50 | Автор: admin


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

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

Recovery mode Собираем сервер для графических и CADCAM приложений для удаленной работы по RDP на базе бу CISCO UCS-C220 M3 v2

04.07.2020 20:20:46 | Автор: admin
imageПочти у каждой компании сейчас обязательно есть отдел или группа работающая в CAD/CAM
или тяжелых дизайнерских программах. Эту группу пользователей объединяет серьёзные требования к железу: много памяти 64ГБ и больше, профессиональная видеокарта, быстрый ssd, и чтобы было надежное. Зачастую компании покупают некоторым пользователям таких отделов несколько мощных ПК (или графических станций) и остальным менее мощные в зависимости от потребностей, а также финансовых возможностей компании. Зачастую это стандартный подход для решения таких задач, и он нормально работает. Но во время пандемии и удаленной работы, да и в общем такой подход неоптимален, очень избыточен и крайне неудобен в администрировании, управлении и прочих аспектах. Почему это так, и какое решение идеально удовлетворит потребности в графических станциях многих компаний? Прошу пожаловать под кат, где описано как собрать рабочее и недорогое решение, чтобы убить накормить сразу нескольких зайцев, и какие мелкие нюансы нужно учесть, чтобы успешно внедрить это решение.
В декабре прошлого года одна компания открывала новый офис для небольшого КБ и была поставлена задача организовать им всю компьютерную инфраструктуру учитывая, что ноутбуки для пользователей и пару серверов у компании уже есть. Ноутам уже было пару лет и это были в основном игровые конфигурации с 8-16ГБ ОЗУ, и в основном не справлялись с нагрузкой от CAD/CAM приложений. Пользователи должны быть мобильными, так как часто необходимо работать не из офиса. В офисе к каждому ноуту дополнительно покупается еще по монитору (так работают с графикой). При таких входных данных единственно оптимальное, но рискованное для меня решение внедрить мощный терминальный сервер с мощной профессиональной видеокартой и nvme ssd диском.

Преимущества графического терминального сервера и работы по RDP


  • На отдельных мощных ПК или графических станциях большую часть времени аппаратные ресурсы не используются даже на треть и простаивают без дела и только короткий период времени используются в 35-100% своей мощности. В основном КПД составляет 5-20 процентов.
  • Но часто аппаратная часть далеко не самая затратная составляющая, ведь базовые графические или САД/CAM лицензии на ПО часто стоят от 5000$, а если еще с расширенными опциями то и от 10 000$. Обыкновенно в сеансе RDP эти программы запускаются без проблем, но иногда необходимо дозаказывать RDP опцию, либо поискать по форумам что прописать в конфигах или реестре и как запустить в сеансе RDP такое ПО. Но проверить, что нужное нам ПО работает по RDP нужно в самом начале и сделать это просто: пробуем зайти по RDP если программа запустилась и работают все базовые программные функции, то и проблем с лицензиями скорее всего не будет. А если выдает ошибку, то перед реализацией проекта с графическим терминальным сервером, ищем удовлетворительное для нас решение проблемы.
  • Также большим плюсом есть поддержка одинаковой конфигурации и специфических настроек, компонентов и шаблонов, что часто труднореализуемо для всех ПК пользователей. Управление, администрирование и обновление ПО тоже без сучка и задоринки

В общем плюсов много посмотрим как на деле покажет наше почти идеальное решение.

Собираем сервер на базе бу CISCO UCS-C220 M3 v2


Изначально планировалось купить поновее и мощный сервер с 256ГБ DDR3 ecc памятью и 10GB ethernet, но сказали что нужно немного сэкономить и вписаться в бюджет на терминальный сервер 1600$. Ну ладно клиент всегда жадный прав и подбираем под эту сумму:
бу CISCO UCS-C220 M3 v2 (2 X SIX CORE 2.10GHZ E5-2620 v2) \128ГБ DDR3 ecc 625$
3.5" 3TB sas 7200 з США д 2x65$=130$
SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512GB Samsung 200$
Видеокарта QUADRO P2200 5120MB 470$
Адаптер Ewell PCI-E 3.0 to M.2 SSD (EW239) -10$
Итого за сервер = 1435$
Планировалось брать ssd 1TB и 10GB ethernet adapter 40$, но выяснилось, что UPS к их 2 серверам не было, и пришлось немного ужаться и купить UPS PowerWalker VI 2200 RLE -350$.

Почему сервер, а не мощный ПК? Обоснование выбранной конфигурации.


Многие недальновидные админы (много раз уже сталкивался) почему то покупают мощный (зачастую игровой ПК), ставят там 2-4 диска, создают RAID 1, гордо называют это сервером и ставят его в углу офиса. Естественна вся комлектуха сборная солянка сомнительного качества. Поэтому распишу подробно почему подобрана под такой бюджет именно такая конфигурация.
  1. Надежность!!! все серверные комплектующие спроектированы и протестированы для работы более 5-10 лет. А игровые мамки от силы работают 3-5 лет и даже процент поломки во время гарантийного срока у некоторых превышает 5%. А наш сервер от супернадежного бренда CISCO, так что особых проблем не предвидится и их вероятность на порядок ниже стационарного ПК
  2. Важные компоненты типа блока питания дублируются и в идеале можно подать питание с двух разных линий и при выходе из строя одного блока сервер продолжает работать
  3. Память ECC сейчас мало кто помнит, что изначально память ECC была введена для коррекции одного бита от ошибки, возникающей в основном от воздействия космических лучей, а на объёме памяти 128ГБ ошибка может возникать несколько раз в году. На стационарном ПК мы можем наблюдать вылет программы, зависание и прочее, что некритично, но на сервере цена ошибки иногда очень высока (например неправильная запись в БД), в нашем случае при серьезном глюке надо перегрузится и иногда это стоит дневной работы нескольких человек
  4. Масштабируемость часто потребность компании в ресурсах вырастает в несколько раз за пару лет и в сервер легко добавить памяти дисков, поменять процессоры (в нашем случае шестиядерные E5-2620 на десятиядерные Xeon E5 2690 v2) на обычном ПК почти никакой масштабируемости
  5. Серверный формат U1 серверы должны стоять в серверных! и в компактных стойках, а не кочегарить(до 1КВт тепла) и шуметь в углу офиса! Как раз в новом офисе компании отдельно предоставлялось немного (3-6 юнитов) место в серверной и один юнит на наш сервер как раз был нам впритык.
  6. Удаленные: управление и консоль без этого нормальное обслуживание сервера для удаленной! работы крайне затруднительно!
  7. 128Гб ОЗУ в ТЗ было сказано 8-10 пользователей, но в реальности будет 5-6 одновременных сессий поэтому учитывая типичный в той компании максимальный расход объёма памяти 2 пользователя по 30-40ГБ=70ГБ и 4 юзера по 3-15ГБ=36ГБ, + до 10ГБ на операционку в сумме 116ГБ и 10% у нас в запасе(это все в редких случаях максимального использования. Но если будет не хватать то в любой момент можно добавить до 256ГБ
  8. Видеокарта QUADRO P2200 5120MB в среднем на пользователя в той компании в
    удаленном сеансе расход видеопамяти был от 0,3ГБ до 1,5ГБ, так что 5ГБ будет достаточно. Исходные данные были взяти с аналогичного, но менее мощного решения, на базе i5/64ГБ/Quadro P620 2ГБ, которого хватало на 3-4 пользователя
  9. SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512GB Samsung для одновременной работы
    8-10 пользователей, необходимо именно скорости NVMe и надежность ssd Samsung. По функционалу этот диск будет использоваться для ОС и приложений
  10. 2х3TB sas объединяем в райд 1 используем для объёмных или редкоиспользуемых локальных данных пользователей, а также для бекапа системы и критическо важных локальных данных с диска nvme

Конфигурация одобрена и куплена, и вот скоро настанет момент истины!

Сборка, настройка, установка и решение проблем.


С самого начала у меня не было уверенности, что это 100% рабочее решение, так как на любом этапе, начиная со сборки заканчивая установкой, запуском и корректной работой приложений можно было застрять без возможности продолжить, поэтому про сервер я договорился, что его в течении пару дней можно будет вернуть, а другие компоненты можно использовать в альтернативном решении.
1 надуманная проблема видеокарта профессиональная, полноформатная! +пару мм, а что если не влезит? 75вт а что если pci разьем не потянет? И как нормальный теплоотвод этих 75вт сделать? Но влезла, запустилась, теплоотвод нормальный(особенно если кулеры сервера включить на обороты выше среднего. Правда когда ставил, для уверенности что бы ничего не замыкало что-то в сервере на 1мм отогнул (уже не помню что), а для лучшего теплоотвода с крышки сервера потом после окончательной настройки отодрал пленку инструкции, которая была на всю крышку и которая могла ухудшать теплоотвод через крышку.
2-е ипытание NVMe диск через переходник мог не увидится либо система туда не поставится, а если поставится, то не загрузится. Как ни странно Windows поставилась на NVMe диск, но загрузится с него не смогла, что логично так как биос(даже обновленный) ни в какую распознавать для загрузки NVMe не хотел. Не хотел костылить, но пришлось тут пришел на помощь наш любимый хабр и пост про загрузку с nvme диска на legacy системах скачал утилитку Boot Disk Utility (BDUtility.exe), создал флешку с CloverBootManager по инструкции из поста, установил флешку в биосе первой на загрузку и вот мы уже грузим загрузчик с флешки, Clover успешно увидел наш NVMe диск и через пару секунд автоматично с него загрузился! Можно было поиграться с установкой clover на наш raid 3TB диск, но было уже субота вечер, а работы оставалось еще на день, ведь до понедельника нужно было или отдавать сервер или оставлять. Загрузочную флешку оставил внутри сервера, там как раз был лишний usb.
3-я почти угроза провала. Поставил Windows 2019 standart +RD сервисы, установил главное приложение, ради которого всё затевалось, и всё чудесно работает и буквально летает. Замечательно! Еду домой и подключаюсь по RDP, приложение запускается, но ощущается серьёзный лаг, смотрю а в проге сообщение включен soft режим. Чего?! Ищу более свежие и суперпрофессиональные дрова на видеокарту, ставлю -результата ноль, более древние дрова под p1000 тоже ничего. А в это время внутренний голос всё издевается а я тебе говорил не экспериментируй со свежачком возьми p1000. А время уже давно ночь во дворе, с тяжелым сердцем ложусь спать. Воскресенье, еду в офис ставлю в сервер quadro P620 и тоже по RDP не работает MS в чем дело? Ищу по форумам 2019 server и RDP ответ нашел почти сразу. Оказывается, что так как у большинства сейчас мониторы с большим разрешением, а в большинстве серверов встроенный графический адаптер эти разрешения не поддерживает то аппаратное ускорение по умолчанию отключено через групповые политики. Цитирую инструкцию по включению:
  • Open the Edit Group Policy tool from Control Panel or use the Windows Search dialog (Windows Key + R, then type in gpedit.msc)
  • Browse to: Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
  • Then enable Use the hardware default graphics adapter for all Remote Desktop Services sessions

Перезагружаемся все прекрасно по RDP работает. Меняем видеокарту на P2200 опять работает! Теперь когда мы уверены, что решение полностью рабочее приводим все настройки сервера к идеалу, вводим в домен, настраиваем доступ пользователей и прочее, ставим сервер в серверную. Тестируем всей командой пару дней всё идеально работает, на все задачи ресурсов сервера хватает с избытком, минимальный лаг возникающий в результате работы по RDP всем пользователям незаметен. Замечательно задача выполнена на 100%.

Пару моментов, от которых зависит успешность внедрения графического сервера.


Так как на любом этапе внедрения графического сервера в организацию могут возникнуть подводные камни, которые могут создать ситуацию аналогичную как на картинке со сбежавшими рыбкамиimage
то на этапе планирования необходимо сделать несколько простых шагов:
  1. Целевая аудитория и задачи пользователи которые интенсивно работают с графикой и им нужно аппаратное ускорение видеокарты. Успех нашего решения основан на том, что потребности в мощности пользователей графических и CAD/CAM программ был удовлетворен с избытком более 10 лет назад, а на данный момент мы имеем запас мощности превышающий потребности в 10 и более раз. Например мощности GPU Quadro P2200 хватает с избытком на 10 пользователей, и даже при недостатке памяти видеопамяти видеокарта добирает с ОЗУ, и для обычного 3d разработчика такое небольшое падение в скорости памяти проходит незаметно. Но если в задачах пользователей есть интенсивные вычислительные задачи (рендеринг, расчеты и прочее), которые часто задействуют 100% ресурсов то наше решение не подходит, так как другие пользователи в эти периоды не смогут нормально работать. Поэтому тщательно анализируем задачи пользователей и текущую загрузку ресурсов (хотя бы приблизительно).
  2. Исходя из количества пользователей подбираем подходящий по ресурсам сервер, видеокарту и диски:
    процессоры по формуле 1 ядро на пользователя + 2,3 на ОС, все равно каждый в один момент времени не использует одного или максимум двух(при редкой загрузке модели) ядер;
    видеокарта -смотрим средний объём потребления видеопамяти и GPU на пользователя в сеансе RDP и подбираем профессиональную! видеокарту;
    аналогично поступаем с ОЗУ и дисковой подсистемой(сейчас можно даже RAID nvme недорого подобрать).
  3. Тщательно смотрим по документации к серверу (благо все брендовые сервера имеет полную документацию) соответствие по разъёмам, скоростям, питанию и поддерживаемым технологиям, а также физическим размерам, и нормам теплоотвода устанавливаемых дополнительных компонентов.
  4. Проверяем нормальную работу нашего ПО по RDP на отсутствие лицензионных ограничений и наличие необходимых лицензий. Решаем этот вопрос до первых шагов по реализации внедрения.
  5. Продумываем где будет установлен графический сервер, не забываем про UPS и наличие там высокоскоростных ethernet портов и интернет (если нужно), а также соответствие климатических требованиям сервера.
  6. Термин внедрения увеличиваем минимум до 2,5-3 недель, ведь многие даже мелкие необходимые компоненты могут ехать до двух недель, а ведь сборка и настройка проходит несколько дней только обычная загрузка сервера до ОС может быть более 5 минут.
  7. Обговариваем с руководством и поставщиками, что если вдруг на каком либо этапе проект не пойдет или пойдет не так, то можно сделать возврат или замену.
  8. Операционную систему (желательно Windows server 2019 там качественный RDP) устанавливаем вначале в Trial режиме, но ни в коем случае не evaluate (нужно потом переустанавливать с нуля). И только после успешного запуска решаем вопросы с лицензиями и активируем ОС.
  9. Также до внедрения подбираем инициативную группу для проверки работы и объясняем будущим пользователям преимущества работы с графическим сервером. Если это делать после, то увеличиваем риск рекламаций, саботажа и неаргументированных негативных отзывов.

По ощущениям работа по RDP не отличается от работы в локальном сеансе. Часто даже забываешь, что работаешь где-то по RDP ведь даже видео и иногда видеосвязь в сеансе RDP работают без ощутимых задержек, ведь сейчас у большинства подключен высокоскоростной интернет. По скорости и функционалу RDP компания Microsoft сейчас продолжает приятно удивлять и аппаратное ускорение 3D и мультимониторы все что необходимо для удаленной работы пользователям графических, 3D и CAD/CAM программ!
Так что во многих случаях установка графического сервера согласно проведенного внедрения является предпочтительней и мобильней 10 графических станций или ПК.
P.S. Как просто и безопасно подключиться через интернет по RDP, а также оптимальные настройки для RDP клиентов вы можете подсмотреть в статье "Удаленная работа в офисе. RDP, Port Knocking, Mikrotik: просто и безопасно"
Подробнее..

Музейный комплекс Зоя танк под обстрелом проекторов и другие технические нюансы

02.07.2020 10:04:35 | Автор: admin


Ян, сколько можно сбивать проекторы?! Когда вы уже закончите свой танк крутить?! Ну вот, опять сетка на сшивке сбилась, опять переделывать!
Дмитрий, выключите, наконец, болгарку. Когда я буду направленный звук отстраивать, ночью?
Иммерсивный музей построить это не ешака купить сложный проект, который требует безупречного взаимопонимания между всеми участниками процесса.
Сегодня мы расскажем о том, как оснащали новый музейный комплекс Зоя в Петрищево мультимедийными системами. Под катом подробности работы в окопе, особенности акустики в землянке и много других нюансов.

Техническая сводка


По традиции сначала скажу пару слов о техническом оснащении музея. Оборудование мы подбирали на этапе проектирования, и в итоге получился следующий стек:
  • плееры BrightSign на них собраны почти все экспозиции;
  • сервер и серверное ПО Screenberry для сшивки и обеспечения работы одной из экспозиций;
  • проекторы Canon остановились на них, так как требовались достаточно тихие проекторы с хорошим сдвигом линз;
  • Акустика и Dante-усилители Bose;
  • ЖК-панели NEC.




Техническое оснащение: путем экскурсанта


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

Страна молодых


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



Школьный класс


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

Когда посетители заходят в помещение, экскурсовод запускает программу: день сменяется ночью. Голос Молотова объявляет о начале войны. Звучат автоматные очереди, взрывы. За окном пролетают самолеты. Программа длится 5 минут, после чего возвращается дневной свет.



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

Что касается организационных моментов, нужно было определиться, как именно начинается шоу. Обсуждалось два варианта работы зала: с экскурсоводом и автоматический. Остановились на первом варианте. Как только заходит группа, экскурсовод закрывает двери и по кнопке запускает программу. Чтобы никто случайно не открыл дверь во время сеанса, над входом в зал висит табло с обратным отсчетом до конца программы. Шоу достаточно громкое, а в музеях существуют определенные нормативы по уровню шума. Одна группа не должна мешать другой.
Возможность повторного нажатия кнопки ограничивается логикой на уровне процессора Crestron сетевые команды на плеер и DMX-контроллер не отправляются до окончания шоу.

Деревня Петрищево


Зимний лес. Шумят деревья, под ногами хрустит снег. Чуть впереди бревенчатые домики деревни Петрищево. Слышно, как вдалеке разрываются снаряды и лают собаки.



Звуки леса зациклены и проигрываются непрерывно. Это фоновая акустика. Вместе с ней в зале присутствуют инсталляции с направленным звуком они циклично транслируют воспоминания родственников и современников Зои. Здесь мы использовали плеер BrightSign и направленную колонку Panphonics с усилителем. Внутри нее несколько десятков миниатюрных динамиков, за счет которых звук концентрируется исключительно под колонкой.

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

Окоп. Битва под Москвой


Очень интересная зона. Она представляет из себя высокий, почти в человеческий рост, окоп, припорошенный снегом. Над посетителями возвышается полноразмерный танк СУ-152 с надписью на борту: За Зою, за сестру!



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

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

Танк привозили и устанавливали по частям около двух суток. Все это время мы с ужасом взирали на тяжелую конструкцию из гипса и МДФ, которая имела все шансы встать между экраном и проекторами. Сделать сшивку с первого раза не получалось физически: во время сбора танка нам 3-4 раза сбивали проекторы. Приходилось заново их выравнивать.



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





Точно так же, как в классе Зои, по нажатию кнопки запускается программа: анимированный вид из окопа заменяется на фильм о битве за Москву, а перед входом загорается обратный отсчет для следующих групп. Хронометраж для таймера берется напрямую из видеофайла, поэтому, если фильм будет заменен, ничего перенастраивать не придется.
Все записи (фото, музыка, звуковые эффекты, видео и т.п.) хранятся на сервере музея, который стоит в отдельном помещении. Как только экскурсовод включает программу, контроллер отдает серверу команду на запуск видео. Параллельно дается команда на табло Не входить, идет сеанс.

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

Землянка


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

Зал Мир помнит о Зое


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

Зал Бессмертного полка


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

Здесь установлены специальные стенды с сенсорными дисплеями. Любой посетитель может указать свои ФИО, отсканировать фото и записать короткий (до 3-х минут) ролик о своем деде или другом воевавшем родственнике. Администрация музея регулярно отсматривает оставленные посетителями материалы и добавляет их в общий видеоряд на стене.



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

Холл


В холле музея установлена видеостена, состоящая из 9 ЖК-панелей NEC. Весь контент поступает с одного плеера (он находится позади стены). Все плееры в музее запитываются по PoE.

Что касается акустики, аудиоплееры передают звук на аудиосистему. Далее по протоколу Dante он маршрутизируется по усилителям и через колонки попадает в уши посетителей.





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

Все системы управляются с ноутбука, на котором установлена панель Crestron с билдом системы управления. Можно мониторить статусы плееров, ЖК-панелей, посмотреть, идет ли сейчас какой-то сеанс. Интерфейс дублируется на планшете, а управление отдано в руки инженеров техподдержки. Все элементы, с которыми взаимодействуют экскурсоводы, сделаны максимально babushka-friendly: нажал на кнопку, и все заработало.

Курьезы и сложности


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

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

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


Похожие публикации


Подробнее..

Как IT гиганты помогают образованию? Часть 1 Google

29.06.2020 16:21:22 | Автор: admin
На старости лет, в свои 33 года, решил я пойти в магистратуру по компьютерным наукам. Первую свою вышку я закончил ещё в 2008 и совсем не в сфере ИТ, много воды с тех пор утекло. Как и любому другому студенту, ещё и со славянскими корнями, мне стало любопытно: что я могу получить на халяву (в основном в плане дополнительных знаний по специальности)? И, коль скоро моё прошлое и настоящее плотно пересекается с хостинг-индустрией, основной выбор пал на гигантов, предоставляющих облачные услуги.

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



Сразу за хабракатом немного разочарую. Жителям стран СНГ не очень повезло. Часть вкусных плюшек Google For Education там не доступна. Потому о них я расскажу в конце, специально для тех, кто учится в вузах Европы, Северной Америки и некоторых других стран. Часть из них доступна в урезанном виде, впрочем. Итак, поехали.

G Suite for Education


Многие из нас любят Gmail, Google Drive и ежи с ними. Особо везучие даже успели захватить бесплатные аккаунты почты для своих доменов, ныне известную как G Suite legacy free edition, которой постепенно закручивают гайки. Если кто не знает, G Suite for Education это всё то же, и даже больше.

Любая школа и любой ВУЗ может получить 10000 лицензий (и, соответственно, аккаунтов) на почту, диск, календарь и прочие возможности сотрудничества, предлагаемые G Suite. Единственное ограничение учебное заведение должно иметь государственную аккредитацию и статус некоммерческой.

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

Кроме того, некоторые преподаватели активно заливают материалы лекций на Google Drive и даже создают там же индивидуальные папки для отправки домашки. Другим, впрочем, вполне подходит Moodle, не имеющий отношения к Google. Подробнее о создании аккаунта можно почитать тут. Срок рассмотрения заявки составляет до 2 недель, но по случаю массового удалённого обучения Google обещал рассматривать и подтверждать их быстрее.

Google Colab


Отличный инструмент для любителей Jupyter Notebook. Доступен любому пользователю Google. Очень удобен как для индивидуальной, так и для совместной работы при изучении чего-либо из сферы машинного обучения и data science. Позволяет тренировать модели как на CPU, так и на GPU. Впрочем, для базового изучения Python тоже вполне подойдёт. Мы активно использовали этот инструмент на Методах интерпретации и классификации. Начать коллаборацию можно тут.


Контуры (для искушённых один из слоёв нейронки VGG16) египетского котика делают коллаборацию лучше

Google Classroom


Отличная LMS (learning management system), предоставляемая бесплатно как один из основных продуктов в рамках пакетов G Suite for Education, G Suite for Nonprofit, а также владельцам персональных аккаунтов. Также предоставляется как дополнительная услуга для обычных аккаунтов G Suite. Система перекрёстных разрешений доступа между разными типами аккаунтов несколько запутанная и нетривиальная. Чтобы не залазить в дебри, самый простой вариант всем участникам процессам учителям и ученикам пользоваться аккаунтами одного типа (либо образовательные, либо персональные).

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

Обучающие материалы


Google подготовил несколько различных возможностей научиться работать с их облачными услугами:
  • Подборка курсов на Coursera доступна для прослушивания бесплатно. Студентам из стран, которым особо повезло, предоставляется также возможность бесплатно выполнять практические задания (обычно платная услуга) и получить сертификаты по 13 курсам от Google. Впрочем, Coursera предоставляет по запросу финансовую помощь на свои курсы (т.е. просто предоставляет их бесплатно, если сможете их убедить, что Вам это очень надо, но денег нет но Вы держитесь). Некоторые курсы доступны полностью бесплатно до 31.07.2020.
  • Ещё одна подборка на Udacity
  • Вебинары Cloud OnAir рассказывают о возможностях и об интересных кейсах, созданных на базе Google Cloud.
  • Google Dev Pathways подборки статей и упражнений, раскрывающий различные темы, касающиеся работы с Google Cloud. Доступны для бесплатно для всех пользователей Google.
  • Codelabs подборка руководств по совершенно различным аспектам работы с продуктами Google. Пути (Pathways) из прошлого пункта являются упорядоченными подборками лабораторок отсюда.

Google for Education


Определённая подборка возможностей по изучению работы с услугами Google доступна лишь для ограниченного круга стран. Грубо говоря, страны ЕС/ЕЭЗ, США, Канада, Австралия, Новая Зеландия. Я учусь в Латвии, так что погреть руки об эти возможности получилось. Если Вы также учитесь в одной из упомянутых стран, наслаждайтесь.
  • Возможности для студентов:
    • 200 кредитов на прохождение интерактивных лабороторок на Qwiklabs.
    • Бесплатный доступ к платным версиям 13 курсов от Coursera (уже упоминал выше).
    • $50 кредитов Google Cloud (на момент написания статьи временно не предоставляется; однако всё равно можно получить тестовые $300, предлагаемые по дефолту при активации пробной подписки).
    • Скидка 50% на сертификацию G Suite.
    • Скидка 50% на экзамен Associate Cloud engineer (зарегистрироваться в программе должен представитель факультета).
  • Возможности для факультетов:
    • 5000 кредитов Qwiklabs, которыми можно поделиться со студентами.
    • $300 кредитов Google Cloud на проведение курсов и различных мероприятий.
    • $5000 кредитов Google Cloud на проведение исследовательских программ (на каждую программу).
    • Программа готовности к карьере бесплатные обучающие материалы и скидка на сертификацию Associate Cloud engineer для студентов и преподавателей.
  • Возможности для исследователей:
    • Соискатели докторской степени (PhD) могут получить $1000 кредитов Google Cloud для своих исследований.

В официальной информации сказано, что Google работает над расширением географии, но есть предположение, что в скором времени ожидать его не стоит.

Вместо заключения


Надеюсь, было полезно. Делитесь информацией со знакомыми студентами, преподавателями и деканами. Если Вы знаете ещё какие-то образовательные предложения от Google, пишите в комментариях. Подписывайтесь на нас, чтобы не пропустить продолжение о различных образовательных возможностях.

От себя хотим также предложить всем студентам скидку 50% на первый год использования наших услуг хостинга и облачных VPS, а также VPS с выделенными накопителями. Для этого Вам необходимо зарегистрироваться у нас, сделать заказ и, не оплачивая его, написать тикет в отдел продаж, предоставив фото себя со своим студенческим. Сотрудник отдела продаж скорректирует Вам стоимость заказа в соответствии с условиями акции.

И всё, другой рекламы не будет.
Подробнее..

Как IT гиганты помогают образованию? Часть 2 Microsoft

02.07.2020 12:23:15 | Автор: admin
В прошлом посте я рассказывал, о том, какие возможности предоставляет Google для студентов и образовательных учреждений. Для тех, кто его пропустил, вкратце напомню: я в свои 33 пошёл в магистратуру в Латвии и открыл для себя дивный мир бесплатных возможностей для студентов получить знания от лидеров рынка, а также для преподавателей сделать свои занятия более близкими к рынку. В этом посте речь пойдёт о том, что предлагает студентам и преподавателям Microsoft.


Office 365 для образования


Сколько бы ни существовало различных бесплатных альтернатив, всё же 3 наиболее популярные программы из пакета Office Word, Excel, PowerPoint остаются наиболее удобными, как по мне. LibreOffice всё же немного коряв визуально, а у Google Docs возможности по форматированию чуть поменьше.

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

Azure для учащихся


Естественно, не обошлось без бонусов для доступа к Azure облачным услугам, предоставляемым Microsoft. Жители более 140 стран могут получить бесплатный доступ к 25 облачным услугам и средствам разработки, а также $100 на баланс, которые можно использовать на другие сервисы. Через 12 месяцев, если Вы всё ещё студент, сумму и срок действия можно обнулить.

Преподавателям традиционно предлагается сумма побольше $200. Материалы для практических работ доступны всем желающим.

Для получения плюшек опять-таки нужен e-mail образовательного учреждения, зато не нужна кредитная карточка (напомню, что она требуется для регистрации обычного trial аккаунта). Но и это ещё не всё. В пакет также входят некоторые приятные плюшки:

Обучающие материалы


Внутри кабинета Azure для учащихся доступны короткие практические обучающие материалы, позволяющие раскрыть и пощупать шаловливыми ручками возможности платформы. Отличное применение для начисленных $100.



Инструменты и средства для разработки


Список тут довольно обширный. Из того, что заинтересовало меня: Visual Studio 2019 Enterprise (использовал на одном из предметов, т.к. нужные возможности CLion не завелись), Microsoft Visio, Microsoft Project (пригодились на другом предмете), Windows 10 Education (просто пригодилась), серверные версии Windows



WintellectNOW


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



Pluralsight


Ещё одна подборка курсов, более интерактивная. Доступ предоставляется лишь к ограниченному набору курсов, спонсированному Microsoft. Тут также встречаются темы как общей направленности, так и конкретно по работе с возможностями Azure.



Microsoft Learn


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

Центр преподавателей


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

Вместо заключения


Надеюсь, было полезно. Делитесь информацией со знакомыми студентами, преподавателями и деканами. Если Вы знаете ещё какие-то образовательные предложения от Microsoft, пишите в комментариях. Подписывайтесь на нас, чтобы не пропустить продолжение о различных образовательных возможностях.

От себя хотим также предложить всем студентам скидку 50% на первый год использования наших услуг хостинга и облачных VPS, а также VPS с выделенными накопителями. Для этого Вам необходимо зарегистрироваться у нас, сделать заказ и, не оплачивая его, написать тикет в отдел продаж, предоставив фото себя со своим студенческим. Сотрудник отдела продаж скорректирует Вам стоимость заказа в соответствии с условиями акции.

И опять другой рекламы не будет.
Подробнее..

Размещаем сайт на домашнем роутере

04.07.2020 18:11:54 | Автор: admin
Мне давно хотелось потрогать руками интернет-сервисы, настроив веб-сервер с нуля и выпустив его в Интернет. В этой статье хочу поделиться полученным опытом превращения домашнего роутера из узкофункционального устройства в практически полноценный сервер.

Началось всё с того, что служивший верой и правдой роутер TP-Link TL-WR1043ND перестал удовлетворять потребности домашней сети, захотелось 5ГГц диапазона и быстрого доступа к файлам на накопителе, подключенном к роутеру. Просмотрев профильные форумы (4pda, ixbt), сайты с отзывами и посмотрев на ассортимент местных магазинов решил приобрести Keenetic Ultra.

В пользу именно этого устройства сработали хорошие отзывы владельцев:
отсутствие проблем с перегревом (тут пришлось отказаться от продукции Asus);
надежность в работе (тут вычеркнул TP-Link);
простота в настройке (побоялся не справиться и вычеркнул Microtik).

Пришлось примириться с минусами:
нет WiFi6, хотелось взять оборудование с запасом на будущее;
4 LAN порта, хотелось больше, но это уже не домашняя категория.

В итоге получилась вот такая серверная:



слева оптический терминал Ростелекома;
справа наш подопытный роутер;
проводом к роутеру подсоединен завалявшийся m.2 SSD на 128 ГБ, помещенный в коробку USB3 с алиэкспресса, сейчас он аккуратно закреплен на стенке;
на переднем плане удлинитель с независимым отключением розеток, провод от него идет к недорогому UPS;
на заднем плане пучок витой пары на этапе ремонта квартиры сразу запланировал RJ45 розетки в местах предполагаемого размещения техники, чтобы не зависеть от замусоренности WiFi.

Итак, у нас есть оборудование, необходимо его настроить:



первичная настройка роутера занимает около 2 минут, указываем параметры подключения к провайдеру (у меня оптический терминал переключен в режим бриджа, PPPoE соединение поднимает роутер), название WiFi сети и пароль в принципе всё, роутер запускается и работает.



Ставим переадресацию внешних портов на порты самого роутера в разделе Сетевые правила Переадресация:





Теперь можно перейти к продвинутой части, чего я хотел от роутера:
1) функционал небольшого NAS для домашней сети;
2) выполнение функций веб-сервера для нескольких частных страничек;
3) функционал персонального облака для доступа к личным данным из любой точки мира.

Первое реализуется встроенными средствами, не требуя особых усилий:

берем предназначенный для этой роли накопитель (флешку, карту памяти в картридере, жесткий диск или SSD во внешнем боксе и форматируем в Ext4 с помощью MiniTool Partition Wizard Free Edition (у меня нет компьютера с linux под рукой, там можно встроенными средствами). Как я понимаю, при работе система пишет на флешку только логи, поэтому, если их ограничить после настройки системы можно использовать и карты памяти, если планируете много и часто писать на накопитель лучше SSD или HDD.



После этого подключаем накопитель к роутеру и наблюдаем его на экране системного монитора



Переходим щелчком по USB-диски и принтеры в раздел Приложения и настраиваем общий ресурс в разделе Сеть Windows:



И у нас имеется сетевой ресурс, который можно использовать с компьютеров под Windows, подключив при необходимости как диск: net use y: \\192.168.1.1\SSD /persistent:yes

Скорость такого импровизированного NAS вполне достаточна для домашнего применения, по проводу он использует весь гигабит, по WiFi скорость составляет около 400-500 мегабит.



Настройка хранилища один из необходимых шагов для настройки сервера, далее нам нужно:
приобрести домен и статический IP адрес (можно обойтись и без этого, используя Dynamic DNS, но статический IP у меня уже был, поэтому проще оказалось воспользоваться бесплатными сервисами Яндекса делегировав туда домен, мы получаем DNS-хостинг и почту на своем домене);



настроить DNS сервера и добавить A-записи, указывающие на ваш IP:



Вступление в силу настроек делегирования домена и DNS занимает несколько часов, поэтому параллельно занимаемся настройкой роутера.

Для начала необходимо установить репозиторий Entware, из которого мы сможем ставить на роутер необходимые пакеты. Я воспользовался этой инструкцией, только не заливал установочный пакет по FTP, а создал папку прямо на подключенном ранее сетевом диске и скопировал туда файл обычным способом.

Получив доступ по SSH, меняем пароль командой passwd и ставим командой opkg install [имена пакетов] все нужные пакеты:



В ходе настройки на роутере оказались установлены следующие пакеты (результат вывода команды opkg list-installed):

Список пакетов
bash 5.0-3
busybox 1.31.1-1
ca-bundle 20190110-2
ca-certificates 20190110-2
coreutils 8.31-1
coreutils-mktemp 8.31-1
cron 4.1-3
curl 7.69.0-1
diffutils 3.7-2
dropbear 2019.78-3
entware-release 1.0-2
findutils 4.7.0-1
glib2 2.58.3-5
grep 3.4-1
ldconfig 2.27-9
libattr 2.4.48-2
libblkid 2.35.1-1
libc 2.27-9
libcurl 7.69.0-1
libffi 3.2.1-4
libgcc 8.3.0-9
libiconv-full 1.11.1-4
libintl-full 0.19.8.1-2
liblua 5.1.5-7
libmbedtls 2.16.5-1
libmount 2.35.1-1
libncurses 6.2-1
libncursesw 6.2-1
libndm 1.1.10-1a
libopenssl 1.1.1d-2
libopenssl-conf 1.1.1d-2
libpcap 1.9.1-2
libpcre 8.43-2
libpcre2 10.34-1
libpthread 2.27-9
libreadline 8.0-1a
librt 2.27-9
libslang2 2.3.2-4
libssh2 1.9.0-2
libssp 8.3.0-9
libstdcpp 8.3.0-9
libuuid 2.35.1-1
libxml2 2.9.10-1
locales 2.27-9
mc 4.8.23-2
ndmq 1.0.2-5a
nginx 1.17.8-1
openssl-util 1.1.1d-2
opkg 2019-06-14-dcbc142e-2
opt-ndmsv2 1.0-12
php7 7.4.3-1
php7-mod-openssl 7.4.3-1
poorbox 1.31.1-2
terminfo 6.2-1
zlib 1.2.11-3
zoneinfo-asia 2019c-1
zoneinfo-europe 2019c-1


Возможно, тут что-то лишнее затесалось, но места на накопителе много, поэтому разбираться не стал.

После установки пакетов настраиваем nginx, я пробовал с двумя доменами на втором настроен https, и пока висит заглушка. 81 и 433 внутренние порты вместо 80 и 443 используются, поскольку на нормальных портах висят админки роутера.

etc/nginx/nginx.conf
user nobody;
worker_processes 1;
#error_log /opt/var/log/nginx/error.log;
#error_log /opt/var/log/nginx/error.log notice;
#error_log /opt/var/log/nginx/error.log info;
#pid /opt/var/run/nginx.pid;

events {
worker_connections 64;
}

http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log /opt/var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;

server {
listen 81;
server_name milkov.su www.milkov.su;
return 301 milkov.su$request_uri;
}

server {
listen 433 ssl;
server_name milkov.su;
#SSL support
include ssl.conf;
location / {
root /opt/share/nginx/html;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}

etc/nginx/ssl.conf
ssl_certificate /opt/etc/nginx/certs/milkov.su/fullchain.pem;
ssl_certificate_key /opt/etc/nginx/certs/milkov.su/privkey.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
ssl_dhparam /opt/etc/nginx/dhparams.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_stapling on;


Для того, чтобы сайт работал по https, воспользовался известным скриптом dehydrated, установив его по этой инструкции. Затруднений этот процесс не вызвал, запнулся только на том, что в тексте скрипта для работы на моем роутере надо закомментировать строчку в файле /opt/etc/ssl/openssl.cnf:

[openssl_conf]
#engines=engines

И отмечу, что генерация dhparams.pem командой openssl dhparam -out dhparams.pem 2048 на моем роутере занимает больше 2 часов, если бы не индикатор прогресса потерял бы терпение и перезагрузил.

После получения сертификатов перезапускаем nginx командой "/opt/etc/init.d/S80nginx restart". В принципе на этом настройка закончена, но сайта еще нет если положим в каталог /share/nginx/html файл index.html, увидим заглушку.
index.html
<!DOCTYPE html>
Тестовая страничка!


Тестовая страничка!


Это простая статическая тестовая страничка, абсолютно ничего интересного.






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

Выбираем подходящий шаблон там есть на самые разные случаи, скачиваем архив, и раcпаковываем его в каталог /share/nginx/html, делать это можно уже со своего компьютера, затем редактируем шаблон (тут потребуются минимальные знания HTML, чтобы не нарушить структуру) и заменяем графику, как показано на рисунке ниже.



Резюме: роутер вполне пригоден для размещения на нем легкого сайта, в принципе если не предполагается большой нагрузки, можно поставить и php, и экспериментировать с более сложными проектами (смотрю на nextcloud/owncloud, вроде есть успешные установки на такое железо). Возможность установки пакетов поднимает его полезность например, когда надо было защитить RDP порт ПК в локальной сети, поставил knockd на роутер и проброс порта к ПК открывался только после port knocking.

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

NewNode децентрализованная CDN от разработчика FireChat

03.07.2020 14:20:11 | Автор: admin


На днях я наткнулся на упоминание некоего NewNode:
NewNode SDK для мобильной разработки, который делает любое приложение неубиваемым для любой цензуры и DDoS, и драматически снижает нагрузку на сервере. P2P сеть. Может работать в теории без интернета.


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

dCDN


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

Протокол


Далее выясняется, что NewNode это peer-to-peer протокол, на котором уже строится dCDN. Он обещает высокую скорость, что обычно вызывает проблемы у децентрализованных сетей. Формально протокол нигде не описан, но из пдфки можно понять, что работает он использует:
  • LEDBAT
  • Bittorrent DHT
  • Соединения device-to-device из FireChat

Отдельным пунктом указано свойство сетей на NewNode разворачиваться и чиниться автоматически (последнее, скорее всего, подразумевает нестабильность mesh-сети из мобильных устройств). Также, поскольку разработчики надеются внедрить поддержку протокола во все возможные приложения, трафик, генерируемый NewNode'ом не будет демаскировать пользователя. Заявлена защита от DDoS и отдельно выделена фраза:
Take advantage of BitTorrents 250 Million user base


Вообще непонятно, что этим хотели сказать и как обращение к Bittorrent DHT в протоколе приравняли к юзербазе Bittorrent'а.

Работа без интернета, очевидно, наследуется от технологий FireChat, но непонятно в каких пределах. В единственной строчке про офлайн заявлен доступ к вашему контенту, что скорее всего означает проброс входящих данных через соседний клиент с интернетом по mesh-сети.

Репозиторий


В нём лежат SDK под Android, iOS и macOS/Linux. За три с половиной года существования проекта в нём отметились 4 контрибьютора, но по сути весь код написан одним разработчиком Greg Hazel. Тут я, конечно, приуныл вся эта амбициозная мишура оказалась по сути пет-проектом одного разработчика. Но кое-что обнадёживает меня.



Отдельные связи стали выстраиваться ещё на сайте, а порывшись в гитхабе, я вспомнил окончательно. CEO Clostra, разрабатывающей проект, и один из контрибьюторов Станислав Шалунов, один из разработчиков FireChat и автор Low Extra Delay Background Transport (LEDBAT), по которому ходит Bittorrent, Apple и наверняка что-то ещё. Теперь он ещё и инвестор, и очень похоже на то, что он планирует всерьёз развивать свой протокол и сделать его общепринятым (или хотя бы общеизвестным, как это произошло с LEDBAT).

Что ещё смущает


Помимо полной зависимости от одного разработчика, есть и другие странности вокруг этого проекта.
  • О нём никто нигде не пишет. Ни на HN, ни в бложиках или твиттерах. Полный информационный вакуум. Я даже не знаю откуда про него узнал тот человек, который написал характеристику из начала поста.
  • Если идея действительно хороша, её, пользуясь личным брендом и авторитетом Шалунова, можно было бы давно раскрутить и обзвестись поддержкой крупных игроков (или крупного комьюнити). Ничего этого нет.
  • Clostra очень мутная студия. Прямо очень. У них крайне стрёмного вида сайт, на котором они представляют свой единственный продукт Keymaker (ну и NewNode), всё без примеров, отзывов, скриншотов и прочей туфты, обязательной для лендинга. Там просто воодушевляющий текст в размытых формулировках и иконки с ближайшего стока. Нельзя изучить команду, вакансии или вообще что-то узнать про эту контору. У них есть твиттер, который судя по всему ведёт бот, и заброшенный в момент создания фейсбук. Но при всей этой внешней стрёмности они в нескольких местах подчёркивают факт своего сотрудничества с госслужбами, особенно с Department of Defence. Есть три отзыва про устройство к ним на работу, где два резко негативные (например, Don't waste your time with Clostra. Something stinks about this scam, а один очень положительный. В общем, на первый взгляд от скама такой проект не отличить.


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



На правах рекламы


Эпичные серверы это надёжные VDS на базе KVM с новейшими процессорами AMD EPYC. Как и для других типов серверов, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата.

Подробнее..

Стартап Nautilus Data Technologies готовит к спуску на воду новый дата-центр

22.06.2020 18:15:30 | Автор: admin


В индустрии дата-центров работа продолжается, несмотря на кризис. Например, стартап Nautilus Data Technologies недавно заявил о намерении запустить новый плавучий ДЦ. О Nautilus Data Technologies стало известно несколько лет назад, когда компания сообщила о планах разработать плавучий дата-центр. Казалось, это очередная идея-фикс, которая никогда не будет реализована. Но нет, в 2015 году компания начала работу над своим первым дата-центром Eli M. Его плавучая основа была спущена на воду в 30 километрах от Сан-Франциско. Мощность ДЦ составила 8 МВт, а вместимость 800 серверных стоек.

Стартап ранее получил около $36 миллионов инвестиций от разных партнеров. Сейчас в него вложился крупнейший инвестор компания Orion Energy Partners. Инвестировала она в водоплавающие дата-центры $100 млн. Средства пойдут на расширение возможностей дата-центров, создание дополнительных объектов, новые исследования и т.п.


Двухпалубный дата-центр от Nautilus Data Technologies с модульной структурой

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

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

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


Внешний вид нового дата-центра

Положительным моментом здесь является система охлаждения. Она водная, и для ее создания не нужно разворачивать сложную систему подвода и отвода воды. Хладоноситель всегда под рукой. Он набирается прямо из океана или моря (через специальные люки, расположенные ниже ватерлинии плавучей основы), немного очищается и используется для охлаждения. Далее нагретая вода выливается обратно в море или океан. Благодаря тому, что воду не нужно качать по трубопроводам издалека, энергопотребление ДЦ ниже, чем у стандартного объекта аналогичной мощности. У тестового дата-центра компании PUE составил 1,045, на реальном объекте он чуть выше 1,15. По расчетам, проведенным специалистами по охране окружающей среды, негативное влияние на окружающую среду будет минимальным. Локальная и тем более глобальная экосистемы не пострадают.


Так выглядит система охлаждения серверов на базе теплообменников в задней дверце серверной стойки (производитель ColdLogik)

Что касается нового ДЦ, то он уже получил название Stockton I. Строительство ведется в порту Стоктон в северной части штата Калифорния. Согласно плану, в эксплуатацию дата-центр запустят в конце 2020 года. Еще один объект компания Nautilus Data Technologies строит в доках Лимерика в Ирландии. Стоимость создания ирландского ДЦ $35 млн. По словам разработчиков, энергоэффективность плавучих дата-центров на 80% выше обычных, кроме того, плотность стоек в таких объектах в несколько раз выше, чем в стандартных ДЦ. Капитальные затраты снижаются вплоть до 30% по сравнению с аналогичным показателем для стандартного ДЦ.
Подробнее..

Как управлять потоками в ЛВС Цифровой Подстанции?

23.06.2020 14:06:23 | Автор: admin
Введение

Цифровая Подстанция это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?

Всем, кому интересно разобраться в этой теме, welcome под кат!

Как данные передаются в сети и зачем управлять multicast-потоками?

Прежде чем переходить непосредственно к Цифровой Подстанции и нюансам построения ЛВС, предлагаю краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками. Ликбез мы спрятали под спойлер.

Типы передачи данных
Типы траффика в ЛВС

Существует четыре типа передачи данных:
  • Broadcast широковещательная рассылка.
  • Unicast обмен сообщениями между двумя устройствами.
  • Multicast рассылка сообщений на определенную группу устройств.
  • Unknown Unicast широковещательная рассылка с целью найти одно устройство.

Чтобы не запутать карты, давайте, прежде чем переходить к multicast, кратко проговорим про другие три типа передачи данных.

Прежде всего, давайте вспомним, что внутри ЛВС адресация между устройствами выполняется на основе MAC-адресов. В любом передаваемом сообщении есть поля SRC MAC и DST MAC.

SRC MAC source MAC MAC-адрес отправителя.

DST MAC destination MAC MAC-адрес получателя.

Коммутатор на основании этих полей передает сообщения. Он смотрит DST MAC, находит его в своей таблице MAC-адресов и отправляет сообщение на тот порт, который указан в таблице. Также он смотрит и SRC MAC. Если такого MAC-адреса в таблице нет, то добавляется новая пара MAC-адрес порт.

Теперь давайте поговорим подробнее про типы передачи данных.

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


Передача Unicast-трафика

Broadcast
Broadcast это широковещательная рассылка. Т.е. рассылка, когда одно устройство отправляет сообщение всем остальным устройствам в сети.

Чтобы отправить широковещательное сообщение, отправитель в качестве DST MAC указывает адрес FF:FF:FF:FF:FF:FF.


Передача Broadcast-трафика

Unknown Unicast
Unknown Unicast, на первый взгляд, очень похож на Broadcast. Но разница между ними есть сообщение рассылается всем участникам сети, но предназначено только одному устройству. Это как сообщение в торговом центре с просьбой перепарковать авто. Услышат это сообщение все, но откликнется только один.

Когда коммутатор принимает фрейм и не может найти Destination MAC из него в таблице MAC-адресов, то он просто рассылает это сообщение во все порты, кроме того, с которого принял его. На подобную рассылку ответит только одно устройство.


Передача Unknown Unicast-трафика

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

Такая модель передачи данных называется Издатель Подписчик. Есть один Издатель, который отправляет данные и Подписчики, которые эти данные хотят получать подписываются на них.

При multicast-рассылке сообщение отправляется с реального устройства. В качестве Source MAC в фрейме указывается MAC отправителя. А вот в качестве Destination MAC виртуальный адрес.

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


Передача Multicast-трафика

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

Краткий ликбез про MAC-адрес
MAC-адрес это 48-битное значение, которое уникально идентифицирует устройство. Он разбит на 6 октет. Первые три октета содержат информацию о производителе. 4, 5 и 6 октеты назначаются производителем и являются номером устройства.


Структура MAC-адреса

В первом октете восьмой бит отвечает за то, является ли данное сообщение unicast или multicast. Если восьмой бит равен 0, то данный MAC-адрес это адрес реального физического устройства.

А если восьмой бит равен 1, то этот MAC-адрес виртуальный. То есть, этот MAC-адрес принадлежит не реальному физическому устройству, а виртуальной группе.

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

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

Восьмой бит первого октета MAC-адреса

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

В чем суть multicast?
Основная идея multicast с устройства отправляется только одна копия трафика. Коммутатор определяет, на каких портах находятся подписчики, и передает на них данные от отправителя. Тем самым, multicast позволяет значительно сократить данные, передаваемые через сеть.

Как это работает в реальной ЛВС?
Понятно, что недостаточно просто отправлять одну копию трафика на какой-то MAC-адрес, восьмой бит первого октета которого равен 1. Подписчики должны уметь подключаться к этой группе. А коммутаторы должны понимать, с каких портов данные приходят, и на какие порты их необходимо передавать. Только тогда multicast позволит оптимизировать сети и управлять потоками.

Для реализации этого функционала существуют multicast-протоколы. Наиболее распространенные:
  • IGMP.
  • PIM.

В рамках этой статьи мы по касательной расскажем про общий принцип действия этих протоколов.

IGMP
Коммутатор с поддержкой IGMP запоминает, на какой порт приходит multicast-поток. Подписчики должны отправить IMGP Join сообщение для подключения к группе. Коммутатор добавляет порт, с которого пришел IGMP Join, в список нисходящих интерфейсов и начинает передавать multicast-поток туда. Коммутатор постоянно посылает IGMP Query сообщения на нисходящие порты, чтобы проверить, нужно ли продолжать передавать данные. Если с порта пришло сообщение IGMP Leave или не было ответа на сообщение IGMP Query, то вещание на него прекращается.

PIM
У протокола PIM есть две реализации:
  • PIM DM.
  • PIM SM.

Протокол PIM DM действует от обратного, в сравнении с IGMP. Коммутатор изначально рассылает multicast-поток как широковещательный на все порты, кроме того, с которого он был получен. Затем отключает поток на тех портах, откуда пришли сообщения о том, что он не нужен.

PIM SM по принципу работы близко к IGMP.

Если очень грубо обобщить общий принцип работы multicast Издатель отправляет multicast-поток на определенную MAC-группу, подписчики отправляют запросы на подключение к этой группе, коммутаторы управляют данными потоками.

Почему мы настолько поверхностно прошлись по multicast? Давайте поговорим про специфику ЛВС Цифровой Подстанции, чтобы понять это.

Что такое Цифровая Подстанция и зачем там нужен multicast?

Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:
  • Кто участвует в передаче данных?
  • Какие данные передаются в ЛВС?
  • Какая типовая архитектура ЛВС?

И уже после этого обсуждать multicast

Что такое Цифровая Подстанция?

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

Соответственно, в цифровом виде здесь передаются все данные:
  • Измерения.
  • Диагностическая информация.
  • Команды управления.

Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО Россети определяет следующее определение и критерии ЦПС:

Определение:
Цифровая подстанция автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.

Критерии:
  • дистанционная наблюдаемость параметров и режимов работы оборудования и систем, необходимых для нормального функционирования без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
  • обеспечение телеуправления оборудованием и системами для эксплуатации ПС без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
  • высокий уровень автоматизации управления оборудованием и системами с применением интеллектуальных систем управления режимами работы оборудования и систем;
  • дистанционная управляемость всеми технологическими процессами в режиме единого времени;
  • цифровой обмен данными между всеми технологическими системами в едином формате;
  • интегрированность в систему управления электрической сетью и предприятием, а также обеспечение цифрового взаимодействия с соответствующими инфраструктурными организациями (со смежными объектами);
  • функциональная и информационная безопасность при цифровизации технологических процессов;
  • непрерывный мониторинг состояния основного технологического оборудования и систем в режиме онлайн с передачей необходимого объема цифровых данных, контролируемых параметров и сигналов.


Кто участвует в передаче данных?

В составе Цифровой Подстанции есть следующие системы:
  • Системы релейной защиты. Релейная защита это практически сердце Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
    Горизонтальная связь общение терминалов между собой.
    Вертикальная связь общение с сервером АСУ ТП.
    Измерения общение с измерительными устройствами.

  • Системы коммерческого учета электроэнергии.Системы коммерческого учета общаются только с измерительными устройствами.

  • Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.

Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже пишите в комментарии. Расскажем про это отдельно ;-)

Какие данные передаются в ЛВС?

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


Структурная схема электроэнергетического объекта в соответствии с МЭК 61850

На структурной схеме изображены шины:
  • Мониторинг/Управления.
  • Передача сигналов РЗА.
  • Передача мгновенных значений напряжений и токов.

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

Через шину Передача сигналов РЗА терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.

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

Также к шине Передача мгновенных значений напряжений и токов подключается сервер АСКУЭ, который также забирает к себе измерения для учета.

А шина Мониторинг/Управление служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.

С сервера АСУ ТП данные отправляются в диспетчерский пункт.

Какая типовая архитектура ЛВС?

Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.

На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.

Архитектура Цифровой Подстанции

На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.

Архитектура разбита на три уровня:
  • Уровень станции/подстанции.
  • Уровень присоединения.
  • Уровень процесса.

Уровень станции/подстанции включает в себя АРМы и сервера.

Уровень присоединения включает в себя все технологическое оборудование.

Уровень процесса включает в себя измерительное оборудование.

Также есть две шины для объединения уровней:
  • Шина станции/подстанции.
  • Шина процесса.

Шина станции/подстанции объединяет в себе функции шины Мониторинг/Управление и шины Передача сигналов РЗА. А шина процесса выполняет функции шины Передача мгновенных значений напряжения и тока.

Особенности передачи Multicast в Цифровой Подстанции

Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры Издатель-Подписчик. Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.

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

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

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

Поэтому данные должны были передаваться:
  • Надежно.
  • Гарантированно.
  • Быстро.

Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).

GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.

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

Переход от связи точка-точка к ЛВС подхода не изменил. Данные по-прежнему необходимо передавать надежно, гарантированно и быстро. Поэтому для GOOSE-сообщений используется несколько непривычный механизм передачи данных. Про него чуть позже.

Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).

SV-потоки это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой частотой дискретизации.

Частота дискретизации частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.


Частота дискретизации 80 выборок в секунду

Состав SV-потоков описан в МЭК61850-9-2 LE.

SV-потоки передаются через шину процесса.

Шина процесса коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).

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

Зачем необходим multicast?
Как упоминалось выше, для закрытия требований по передаче данных для горизонтальной связи, GOOSE передаются несколько непривычно.

Во-первых, они передаются на канальном уровне и имеют свой Ethertype 0x88b8. Это обеспечивает высокую скорость передачи данных.

Теперь необходимо закрыть требования гарантированности и надежности.

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

Поэтому для передачи GOOSE используется архитектура Издатель-Подписчик.

Архитектура Издатель Подписчик

Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом через чуть больший и так далее. В итоге время увеличивается до Т0.

Принцип передачи GOOSE-сообщений

Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке.

SV-потоки также передаются на канальном уровне, имеют свой Ethertype 0x88BA и передаются по модели Издатель Подписчик.

Нюансы multicast-передачи в Цифровой подстанции
Но в энергетическом multicastе есть свои нюансы.

Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для энергетического multicast используются свои группы для рассылки.

В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО ФСК определяет собственные диапазоны multicast-рассылки.

Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Для GOOSE-сообщений: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее терминалы релейной защиты не поддерживают IGMP или PIM. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.

Другими словами вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой никак.

А SV-потоки это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.

Какой тогда выход?

Простой использовать старые проверенные VLAN.

Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.

Поэтому можно выделить простое правило пусконаладки Сеть не работает? Disable IGMP!

Нормативная база

Но может быть все-таки можно как-то организовать ЛВС Цифровой Подстанции на основе multicast? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:
  • СТО 34.01-21-004-2019 ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВХ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
  • СТО 34.01-6-005-2019 КОММУТАТОР ЭНЕРГООБЪЕКТОВ. Общие технические требования.
  • СТО 56947007-29.240.10.302-2020 Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.

Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО ФСК ЕЭС. СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.

Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.

На этом все про multicast

Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.

Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.

СТО 34.01-21-004-2019 говорит о том, что VLANы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.

СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.

Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.

Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020



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

А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.

Заключение

В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.

Для управления потоками используются старые добрые VLANы. При этом использование VLAN регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.

Полезные ссылки:
Обучающий курс Цифровая подстанция от Phoenix Contact.
Решения для ЦПС от Phoenix Contact.
Подробнее..

Как архитектура HiCampus упрощает организацию кампусных сетевых решений

26.06.2020 16:08:22 | Автор: admin
Предлагаем вашему вниманию краткий обзор новой архитектуры Huawei HiCampus, в основе которой полностью беспроводной доступ для пользователей, IP + POL и интеллектуальная платформа поверх физической инфраструктуры.



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

Зачем нужен HiCampus




Шквал событий, что повлекли за собой пандемия и противостояние ей, волей-неволей побудил многих быстрее прийти к пониманию того, что кампусы это фундамент нового интеллектуального мира. Под обобщающим словом кампус объединены не только офисные зоны, но и исследовательские институты, лаборатории, университеты вместе со студенческими городками и не только.

В одной только России у Huawei на середину 2020 года насчитывается свыше тысячи разработчиков. Мало того, через два-три года их будет приблизительно впятеро больше. А сосредоточены они как раз таки в кампусах, где мы должны обеспечить им бесшовный сервис по запросу, не заставляя их ждать.

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



Между тем на кампусах становится всё больше пользователей, и у тех всё больше устройств. Хорошо ещё, что не каждая куртка пока снабжена Wi-Fi-модулем: умная одежда ещё диковинка, однако не исключено, что вскоре она войдёт в широкий обиход. Как следствие, без радикальных технологических преобразований качество сервиса в сети снижается. Ничего удивительного: потребление трафика увеличивается, растёт расход электроэнергии, а новые сервисы требуют всё больше ресурсов разного толка. Тем временем владельцы бизнеса и советы директоров, зачастую воодушевлённые теми темпами, с какими проходит цифровая трансформация вокруг, в том числе у конкурентов, хотят новых возможностей быстро и дёшево (Как, у нас в офисе нет видеонаблюдения с face recognition? Почему?!). Кроме того, от сетевой инфраструктуры сегодня ждут синергетического эффекта: развёртывать сеть ради одной только сети уже не принято, да и не в духе времени.



Эти проблемы и призвана решить HiCampus. У неё мы выделяем три среза, каждый из которых привносит свои преимущества в архитектуру. Перечислим их в порядке от нижестоящего к вышестоящему:

  • полностью беспроводной;
  • полностью оптический;
  • интеллектуальный.


Полностью беспроводной срез


Базис полностью беспроводного среза продуктовое решение Huawei на основе Wi-Fi шестого поколения. В сравнении с Wi-Fi 5 оно позволяет вчетверо увеличить количество одновременно подключаемых пользователей и избавить обитателей кампуса от необходимости где бы то ни было подсоединяться к сети по проводам.



Новая продуктовая линейка AirEngine, на которой строится беспроводная среда HiCampus, включает в себя точки доступа (ТД) под самые разные сценарии: хотите для индустриальной эксплуатации с IoT, хотите для применения вне помещений. Дизайн, габариты, способы крепления устройств также допускают все мыслимые варианты использования.

Нововведениям в ТД, например увеличенному числу антенн на приём (их теперь 16 штук), мы обязаны своему центру разработки в Тель-Авиве: работающие там наши коллеги привнесли в Wi-Fi 6 многое из своего предыдущего опыта улучшения сетей WiMAX и 5G-сетей, благодаря чему им удалось серьёзно оптимизировать задержки и пропускную способность точек AirEngine. В результате мы оказались в состоянии гарантировать пропускную способность не ниже заданной отметки каждому клиенту: фраза 100 Мбит/с везде в нашем случае не пустой звук.



Как это получилось? Тут ненадолго обратимся к теории. В соответствии с теоремой Шеннона пропускную способность точки доступа определяют (a) количество пространственных потоков, (b) ширина полосы пропускания и соотношение сигнал шум. У Huawei модификации в сравнении с предыдущими продуктами были произведены по всем трём пунктам. Так, наши ТД способны формировать до 12 пространственных потоков в полтора раза больше, чем топовые модели других вендоров. Кроме того, они могут поддерживать восемь пространственных потоков шириной по 160 МГц против в лучшем случае восьми потоков по 80 МГц у конкурентов. Наконец, благодаря технологии Smart Antenna наши точки доступа демонстрируют значительно большую толерантность к интерференции и более высокий уровень RSSI на приёме у клиента.

По итогам 2019 года наши коллеги из Тель-Авива получили высшую награду внутри компании именно за то, что им удалось на чипе с поддержкой Wi-Fi 802.11ax добиться показателя сигнал шум (SNR) выше, чем у другого известного американского производителя. Результат был достигнут как за счёт использования новых материалов, так и с помощью более совершенной алгоритмической базы, зашитой в процессор. Отсюда и другие выгодные стороны Wi-Fi 6 в интерпретации Huawei. В частности, реализован механизм multi-user MIMO, благодаря которому на одного пользователя может быть выделено до восьми пространственных потоков; MU-MIMO рассчитан на то, чтобы задействовать в передаче информации клиентам весь антенный ресурс точки доступа. Конечно, восемь потоков разом не будут отряжены под какой-нибудь смартфон, а вот под ноутбук последнего поколения или VR-комплекс индустриального назначения вполне.



Таким образом, с 16 пространственными потоками на физическом уровне возможно взять планку 10 Гбит/с на точку. На уровне application-трафика эффективность среды передачи данных составит 7880%, или около 8 Гбит/с. Оговоримся, это справедливо в случае с эксплуатацией 160-мегагерцовых каналов. Разумеется, Wi-Fi 6 рассчитан перво-наперво на массовые подключения, и если их десятки, то каждое отдельно взятое не будет таким заоблачно скоростным.



В лабораторных условиях мы неоднократно проводили тесты с помощью утилиты нагрузки iPerf и фиксировали, что две hi-end-точки Huawei из линейки AirEngine, используя восемь пространственных потоков шириной 160 МГц каждый, обмениваются данными на уровне приложений со скоростью около 8,37 Гбит/с. Нужно сделать ремарку: да, прошивка у них специальная, рассчитанная на то, чтобы раскрыть потенциал оборудования в ходе испытаний, однако факт остаётся фактом.

Кстати, у Huawei в России действует Joint Validation Lab с обширным парком Wi-Fi-оборудования. Раньше мы использовали в ней устройства с M.2-чипами других производителей, теперь же показываем производительность Wi-Fi 6 на телефонах собственного производства, например P40.








На иллюстрациях выше видно, что в едином конструктивном блоке, каких в точке доступа четыре штуки, содержится также по четыре элемента итого 16 приёмо-передающих антенн, функционирующих в динамическом режиме. Что касается beamforming, благодаря применению большего количества антенн на элементе удаётся формировать более узкий и длинный луч и надёжнее вести клиента, обеспечивать ему улучшенный user experience.

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





У себя в лабораториях мы не раз проводили тесты на сравнение силы сигнала точек доступа на одинаковом расстоянии покрытия. На иллюстрации выше видно, что на треногах установлены две ТД, поддерживающие Wi-Fi 6: одна (красная) со смарт-антеннами, от Huawei, другая без них. Расстояние от точки до телефона в обоих случаях 13 м. Про прочих равных тот же частотный диапазон 5 ГГц, частота канала 20 МГц и т. д. в среднем разница в силе сигнала между устройствами исчисляется 3 дБм, и преимущество на стороне точки Huawei.







Во втором тесте задействованы те же точки Wi-Fi 6, тот же диапазон 20 МГц, тот же срез 5 ГГц. На расстоянии 13 м существенной разницы не наблюдается, но, как только мы увеличиваем дистанцию вдвое, показатели расходятся почти на порядок (7 дБм) в пользу нашего AirEngine.

Используя технологии 5G DynamicTurbo, благодаря которым на базе беспроводной среды приоритезируется трафик от VIP-пользователей, мы добиваемся сервиса, какого раньше в Wi-Fi-среде не было (например, топ-менеджер компании не будет регулярно спрашивать вас, отчего у него такое слабое соединение). До сих пор они были почти исключительно достоянием мира проводных сетей либо TDM, либо IP Hard Pipe, с выделением MPLS-туннелей.

Также Wi-Fi 6 претворяет в жизнь концепцию бесшовного роуминга. Всё благодаря тому, что модифицирован механизм миграции между точками: сначала пользователь подключается к новой и только потом диссоциируется от старой. Это новшество благотворно отражается на функционировании в таких сценариях, как телефония через Wi-Fi, телемедицина и automotive, а именно работа автономных роботов, беспилотников и т. д, для которых критически важно бесперебойно держать соединение с управляющим центром.



В мини-ролике выше в игровой форме отражён вполне современный кейс применения Wi-Fi 6 от Huawei. У собаки в красном комбинезоне VR-очки подцеплены к точке AirEngine, которая быстро переключается и обеспечивает минимальные задержки в передаче информации. Другому псу повезло меньше: аналогичные очки, надетые ему на голову, подсоединены к ТД другого вендора (из этических соображений, само собой, не станем его называть), и пусть перебои и лаги не фатальные, но мешают накладывать виртуальное окружение на окружающее пространство в реальном времени.



Внутри Китая архитектура применяется вовсю. С применением её решений построено около 600 кампусов, из них добрая половина соответствует принципам HiCampus от начала до конца.

Как показывает практика, эффективнее всего применение HiCampus для совместной работы в офисных пространствах, на умных фабриках с их подвижными автономными роботами AGV, а также в местах массового скопления людей. Например, в пекинском международном аэропорту, где развёрнута сеть Wi-Fi 6, обеспечивающая беспроводные услуги для пассажиров на всей территории; среди прочего благодаря кампусной инфраструктуре аэропорту удалось сократить время ожидания в очереди на 15% и сэкономить 20% на персонале.

Полностью оптический срез






Всё чаще мы строим кампусы по новой модели IP + POL, и вовсе не повинуясь велению прихотей технологической моды. Господствовавший раньше подход, при котором, развёртывая сетевую инфраструктуру в здании, мы тянули оптику до этажа, а дальше делали разводку медью, накладывал на архитектуру суровые ограничения. Достаточно одного того, что при необходимости апгрейда приходилось менять практически всю среду на уровне этажа. Сам материал, медь, тоже не идеален: и с точки зрения пропускной способности, и с точки зрения жизненного цикла, и с точки зрения дальнейшего развития среды. Конечно, медь была всем понятна и позволяла создавать несложные сетевые решения быстро и недорого. Вместе с тем по совокупной стоимости владения и по потенциалу к апгрейду сети медь в 2020 году проигрывает оптике.

Особенно ярко превосходство оптики проступает, когда нужно закладываться на длинный жизненный цикл инфраструктуры (и оценивать расходы на неё вдолгую), а также когда ту ждёт серьёзная эволюция. Например, требуется, чтобы в среде постоянно функционировали 4K-камеры и 8K-телевизоры или другой digital signage с высоким разрешением. В подобных ситуациях наиболее разумным решением будет применение полностью оптической с использованием оптических коммутаторов сети. Раньше стоп-фактором при выборе в пользу такой модели построения кампуса служило малое число конечных терминалов optical network units (ONU). В настоящее же время не только пользовательские машины предполагают возможность подключения через терминалы к оптической сети. В ту же Wi-Fi-точку вставляется приёмопередатчик, работающий с POL-сетью, и мы получаем беспроводной сервис через высокоскоростную оптическую сеть.

Таким образом, полноценно внедрить Wi-Fi 6 можно малой кровью: наладить IP + POL-сеть, присоединить Wi-Fi к ней и спокойно наращивать производительность. Единственное, в случае с Wi-Fi-точками требуется локальное электропитание. В остальном ничто не мешает нам довести сеть до 10 или 50 Гбит/с.



Развёртывание полностью оптических сетей целесообразно в самых разных случаях. Например, им трудно представить альтернативу в старых домах с длинными пролётами. Если вы никогда не занимались ребилдингом здания в центре Москвы, то, поверьте, вам крупно повезло: обычно все проходы для кабеля в таких строениях забиты, и чтобы организовать локальную сеть по уму, подчас приходится делать всё с нуля. В случае же с POL-решением можно проложить оптический кабель, развести его сплиттерами и создать современную сеть.

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









Руководствуясь принципом practice what you preach, в организации сетевых сред по модели IP LAN + POL мы начали с себя. Достроенный полтора года назад огромный, общей площадью помещений более 1,4 млн м, кампус Huawei на озере Суншань (Китай) один из первых кейсов реализации архитектуры HiCampus; его здания, кстати, воспроизводят своим обликом известные памятники европейской архитектуры. Внутри же всё, напротив, современно, насколько только возможно.

Из центрального здания оптические линии расходятся в соседние, подлежащие кампусы, где, в свою очередь, также разводятся по этажам и т. д. Точки доступа Wi-Fi 6, покрывающие всю территорию, соответственно, сидят именно на оптике.

На кампусе реализован целый спектр сервисов, которые требуют стабильного высокоскоростного подключения, в том числе видеонаблюдение с помощью камер высокого разрешения. Служат они, впрочем, не только для видеонаблюдения. На входе в кампус цифровая платформа SmartCampus через эти самые камеры идентифицирует сотрудника по лицу, затем тот прикладывает свой RFID-беджик к пропускному терминалу, и только после успешной аутентификации по двум критериям ему будут открыты двери и предоставлен доступ к беспроводной сети и цифровым сервисам кампуса, проскользнуть внутрь с чужим беджем не удастся. Кроме того, на всей территории комплекса доступны VDI-сервис (cloud desktop), система конференц-связи и многие другие сервисы, завязанные на Wi-Fi 6 с оптическим подключением.

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

Полностью интеллектуальный срез






Поверх физических решений, связанных с оптической и беспроводной средой передачи данных, в HiCampus плотно задействована интеллектуальная платформа Horizon, которая служит целям цифровой трансформации и позволяет извлечь из инфраструктуры больше пользы.

Для задач, связанных с самой инфраструктурой, используется подлежащий слой управления на платформе iMaster NCE-Campus.

Первое её предназначение задействовать технологии машинного обучения для контроля за сетью. В частности, ML-алгоритмы дали возможность реализовать в iMaster NCE модуль CampusInsight O&M 1-3-5: в течение минуты приходят сведения об ошибке, три минуты тратится на её обработку, за пять минут она устраняется (подробнее см. в нашей статье Сетевые продукты и решения Huawei Enterprise для корпоративных заказчиков в 2020 году). Таким образом исправляется ни много ни мало 7590% возникающих ошибок.

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

Когда в сетевой инфраструктуре несколько десятков точек доступа и пара контроллеров, ничто не мешает снимать с них трафик и разбирать его вручную посредством Wireshark. Но когда точек тысячи, контроллеров десятки, а разнесено всё это хозяйство по большой территории, искать неисправности становится многократно труднее. Чтобы упростить задачу, мы разработали решение iMaster NCE CampusInsight (по нему у нас был отдельный вебинар). С его помощью, накапливая информацию с устройств пакеты уровня Layer-1 / Layer-4, можно оперативно находить неисправности в сетевой среде.

Выглядит процесс следующим образом. Платформа, допустим, показывает нам, что у пользователя не ладится с радиоаутентификацией. Она проводит анализ и указывает, на каком шаге возникла проблема. И если та связана со средой, то платформа предложит нам решить проблему (в интерфейсе возникает кнопка Resolve). В видео ниже показано, как в системе приходит уведомление о том, что произошёл reject RADIUS: скорее всего, либо пользователь неверно ввёл пароль, либо пароль поменялся. Таким образом, без судорожных попыток разобраться, в чём дело, удаётся сберечь уйму времени, благо все данные сохраняются и предысторию той или иной коллизии легко изучить.



Распространённая история: к вам подходит владелец компании или CTO и сетует на то, что некая важная персона вчера у вас в офисе не сумела подсоединиться к беспроводной сети. Приходится решать вопрос. Возможно, под угрозой потери квартальной премии. В обычной ситуации нельзя устранить проблему, не найдя того самого VIP-пользователя. А что, если это какой-нибудь топ-менеджер или замминистра, с которым и встретиться-то нелегко, тем более попросить у него смартфон, чтобы разобраться в проблеме? Избежать подобных ситуаций помогает продукт Huawei, использующий наш дистрибутив больших данных FusionInsight, который хранит весь накопленный объем знаний о происходившем в сети, благодаря чему до истоков любой неполадки можно дойти путём ретроспективного анализа.



Устройства и их связность дело важное. Но чтобы построить действительно умный кампус, необходима софтверная надстройка.

Прежде всего, в HiCampus поверх физического уровня задействуется облачная платформа. Она может иметь приватное, публичное или гибридное исполнение. На неё, в свою очередь, наслаиваются сервисы для работы с данными. Вся эта совокупность ПО и является цифровой платформой. С концептуальной точки зрения она опирается на принципы Relationship, Open, Multi-Ecosystem, Any-Connect сокращённо ROMA (о них и о платформе в целом также будет отдельный вебинар и пост по его следам). Обеспечивая связь между компонентами среды, Horizon делает её более целостной, что далее находит подтверждение как в бизнес-показателях, так и в комфорте пользователей.

В свою очередь, интеллектуальный центр управления Huawei IOC (Intelligent Operation Center) призван следить за здоровьем кампуса, энергоэффективностью и защищённостью, а главное, даёт общую панораму того, что происходит на кампусе. Скажем, благодаря наглядной схеме визуализации (см. демо) будет видно, что камера среагировала на какой-то тревожный фактор, и можно мигом получить картинку с неё. Если вдруг произошло возгорание, по RFID-датчикам легко проверить, все ли люди покинули помещение.

А благодаря тому, что к точкам доступа Huawei можно подключать дополнительные модули, которые работают по RFID, ZigBee или Bluetooth, нетрудно создать среду, которая будет чутко мониторить ситуацию на кампусе и сигнализировать о самых разных проблемах. Кроме того, с помощью IOC удобно производить инвентаризацию активов в реальном времени, и в целом работа с кампусом как с интеллектуальной единицей открывает массу возможностей.



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

А напоследок добавим, что узнать подробности о наших решениях для smart campus, а отдельные даже попробовать, можно на сайте нашего проекта OpenLab.

***


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

Перевод История интернета, эра фрагментации, часть 4 анархисты

03.07.2020 10:08:54 | Автор: admin


<< До этого: Статисты

Примерно с 1975 по 1995 годы компьютеры становились доступнее гораздо быстрее, чем компьютерные сети. Сначала в США, а потом и в других богатых странах компьютеры стали обычным делом для обеспеченных домохозяйств, и появились почти во всех институтах. Однако если у пользователей этих компьютеров появлялось желание объединить свои машины для обмена электронной почтой, скачивания программ, поиска сообществ для обсуждения любимых хобби у них было не так уж много возможностей. Домашние пользователи могли соединяться с такими сервисами, как CompuServe. Однако до тех пор, пока в конце 1980-х сервисы не ввели фиксированную ежемесячную оплату, стоимость подключения оплачивалась за каждый час, и тарифы были доступны далеко не всем. Некоторые студенты университетов и преподавательский состав могли подсоединяться к сетям с коммутацией пакетов, но большинству это было недоступно. К 1981 году доступ к ARPANET был только у 280 компьютеров. CSNET и BITNET в итоге включат в себя сотни компьютеров, однако они начали работу только в начале 1980-х. А в то время в США было более 3000 институтов, где студенты получали высшее образование, и практически во всех них стояло по несколько компьютеров, от больших мейнфреймов до мелких рабочих станций.

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



Это были одни из самых ранних децентрализованных [peer-to-peer, p2p] компьютерных сетей. В отличие от CompuServe и других централизованных систем, к которым подсоединялись компьютеры, подсасывая у них информацию будто телята молоко, информация распространялась по децентрализованным сетям на манер кругов на воде. Она могла начаться где угодно, и куда угодно прийти. И всё равно в них зародились жаркие споры по поводу политики и власти. Когда в 1990-х внимание сообщества привлёк интернет, многие считали, что он уравняет социальные и экономические связи. Позволив всем связываться со всеми, посредники и бюрократы, доминировавшие в наших жизнях, будут отрезаны. Наступит новая эра прямой демократии и открытых рынков, где у всех будут равные голоса и равный доступ. Такие пророки, возможно, воздержались бы от подобных обещаний, изучив судьбу Usenet и Fidonet 1980-х. Техническая их структура была очень плоской, однако любая компьютерная сеть является лишь частью человеческого сообщества. А человеческие сообщества, как их ни размешивай и не раскатывай, всё равно остаются полны комочков.

Usenet


Летом 1979 жизнь Тома Траскота напоминала мечту любого юного любителя компьютеров. Он недавно получил диплом по информатике в университете Дьюка, интересовался шахматами, и проходил интернатуру в штаб-квартире Лабораторий Белла в Нью-Джерси. Именно там у него был шанс пообщаться с создателями Unix новейшего повального увлечения, захлестнувшего мир научных вычислений.

Истоки Unix, как и самого интернета, лежат в тени американской политики телекоммуникаций. Кен Томпсон и Деннис Ритчи из лабораторий Белла в конце 1960-х решили создать более гибкую и урезанную версию массивной системы Multics из MIT, в создании которой они участвовали как программисты. Новая ОС быстро стала хитом в лабораториях, завоевав популярность как скромными требованиями к железу (благодаря чему она запускалась даже на недорогих машинах) так и высокой гибкостью. Однако AT&T не могла заработать на этом успехе. По соглашению от 1956 года с министерством юстиции США, AT&T была обязана продавать лицензию на все технологии, не связанные с телефонией, по разумным ценам, и не заниматься никаким другим бизнесом, кроме обеспечения коммуникаций.

Поэтому AT&T начала продавать лицензию на Unix университетам для использования в научных целях на очень выгодных условиях. Первые лицензиаты, получившие доступ к исходному коду, начали создавать и продавать собственные варианты Unix, из которых стоит отметить Berkeley Software Distribution (BSD) Unix, созданную в флагманском кампусе Калифорнийского университета. Новая ОС быстро захлестнула академическое сообщество. В отличие от других популярных ОС типа DEC TENEX / TOPS-20, она могла работать на железе различных производителей, и многие из таких компьютеров были весьма недорогими. Беркли распространял программу по незначительной цене, в дополнение к скромной стоимости лицензии от AT&T. К сожалению, точных цифр я найти не смог.

Траскоту казалось, что он находится в источнике всех вещей. Он провёл лето в роли интерна у Кена Томпсона, и начинал каждый день с нескольких волейбольных матчей, затем по наступлению полдня работал, а ужин в виде пиццы делил со своими кумирами, после чего допоздна сидел, записывая код для Unix на языке С. По окончанию интернатуры он не захотел терять связь с этим миром, поэтому, как только он вернулся в университет Дьюка осенью, он придумал, как подсоединить компьютер PDP 11/70 из департамента информатики к кораблю-матке в Мюррей-Хилл при помощи программы, написанной его бывшим коллегой, Майком Леском. Программа называлась uucp Unix to Unix copy и была одной из набора uu-программ, входивших в недавно вышедшую ОС Unix версии 7. Программа позволяла одной Unix-системе связываться с другой по модему. Конкретно, uucp позволяла копировать файлы между двумя соединившимися по модему компьютерами, что позволяло Траскоту обмениваться емейлами с Томпсоном и Ритчи.


Том Траскот

Джим Эллис, ещё один аспирант из института Траскота, установил новую версию Unix 7 на компьютер университета Дьюка. Однако обновление принесло не только плюсы, но и минусы. Распространяемая группой пользователей Unix программа USENIX, предназначенная для рассылки новостей среди всех пользователей конкретной системы Unix, в новой версии перестала работать. Траскот и Эллис решили заменить её новой собственной программой, совместимой с 7-й системой, наделить её более интересными возможностями, и вернуть улучшенную версию в сообщество пользователей в обмен на престиж и почёт.

В то же самое время Траскот использовал uucp для связи с машиной под управлением Unix, стоявшей в университете Северной Каролины, в 15 км к юго-западу, в Чапел-Хилле, и общался с тамошним студентом Стивом Беловиным.

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

Ещё Беловин делал собственную программу для распространения новостей, в которой, что интересно, была концепция новостных групп, разбитым по темам, на которые можно было подписываться вместо одного канала, в который сваливались все новости. Беловин, Траскот и Эллис решили объединить усилия и написать сетевую систему новостей с новостными группами, которая использовала бы uucp для распространения новостей по разным компьютерам. Они хотели распространять новости, связанные с Unix, среди пользователей USENIX, поэтому и назвали свою систему Usenet.

Университет Дьюка должен был служить центральным информационно-аналитическим центром, и использовать автодозвон и uucp, чтобы соединяться со всеми узлами сети через равные промежутки времени, забирать обновления новостей и отдавать новости других членов сети. Беловин написал изначальный код, однако он работал на скриптах программной оболочки, поэтому был очень медленным. Тогда Стивен Дэниел, ещё один аспирант университета Дьюка, переписал программу на С. Версия Дэниела стала известной под названием A News. Эллис рекламировал эту программу в январе 1980 на конференции Usenix в Болдере, Колорадо, и раздал все восемьдесят её копий, принесённых с собой. К следующей конференции Usenix, проходившей летом, её организаторы уже включили A News в пакет программ, распространявшийся среди всех участников.

Создатели описывали эту систему, как ARPANET для бедных. Вы, возможно, не считаете университет Дьюка каким-то второсортным, однако в то время у него не было такого влияния в мире информатики, которое позволило бы ему подключиться к этой премиальной американской компьютерной сети. Но на доступ в Usenet разрешения не требовалось нужна была только система Unix, модем и возможность платить по счетам за телефон за регулярную передачу новостей. К началу 1980-х этим требованиям могли удовлетворить практически все институты, где давали высшее образование.

К Usenet присоединились и частные компании, что способствовало ускорению распространения сети. Digital Equipment Corporation (DEC) согласилась взять на себя роль посредника между университетом Дьюка и Калифорнийским университетом в Беркли, уменьшив стоимость счетов за междугородние звонки и передачу данных между побережьями. В результате Беркли на западном побережье стал вторым узлом Usenet, и соединял сеть с Калифорнийскими университетами в Сан-Франциско и Сан-Диего, а также с другими учреждениями, включая Sytek, одну из первых компаний, занимавшуюся бизнесом, связанным с LAN. В Беркли также располагался и узел ARPANET, что позволило наладить связь между Usenet и ARPANET (после того, как программу обмена новостей ещё раз переписали Марк Хортон и Мэтт Гликман, назвав её B News). Узлы ARPANET начали набирать контент из Usenet и наоборот, хотя правила ARPA, строго говоря, запрещали связываться с другими сетями. Сеть бысто росла, от пятнадцати узлов, обрабатывающих по десять постов в день в 1980, до 600 узлов и 120 постов в 1983, а потом 5000 узлов и 1000 постов в 1987.

Изначально её создатели рассматривали Usenet как способ связи для членов сообщества пользователей Unix и обсуждения разработки этой ОС. Для этого они создали две группы, net.general и net.v7bugs (в последней обсуждались проблемы с новейшей версией). Однако они оставили в системе возможности свободного расширения. Кто угодно мог создать новую группу в иерархии net, и пользователи быстро начали добавлять далёкие от техники темы, к примеру, net.jokes. Точно так же, как кто угодно мог отправлять что угодно, получатели могли игнорировать группы по своему выбору. К примеру, система могла подключиться к Usenet и запрашивать данные только по группе net.v7bugs, игнорируя остальной контент. В отличие от тщательно спланированной ARPANET, Usenet организовывалась самостоятельно, и росла на анархический манер без присмотра сверху.

Однако в этой искусственно демократической среде быстро нарисовался иерархический порядок. Определённый набор узлов с большим количеством связей и большим трафиком стали считать хребтом [backbone] системы. Этот процесс развивался естественным путём. Поскольку каждая передача данных с одного узла на другой добавляла задержку в коммуникациях, каждому новому узлу, подключавшемуся к сети, хотелось связаться с узлом, уже имеющим большое количество подключений, чтобы минимизировать количество скачков, требовавшихся для распространения его сообщений по сети. Среди узлов хребта встречались как образовательные, так и корпоративные организации, и обычно каждым местным компьютером руководил какой-нибудь своенравный человек, добровольно бравший на себя неблагодарное дело по администрированию всего, что проходит через компьютер. Таковы были Гари Мураками из подразделения лабораторий Белла в Индиан-Хилс в штате Иллинойс, или Джин Спэффорд из технологического института Джорджии.

Самое значительное проявление власти администраторов узлов из этого хребта случилось в 1987, когда они продавили реорганизацию пространства имён новостных групп, введя семь новых разделов первого уровня. Там были такие разделы, как comp для компьютерных тем, и rec для развлечений. Подразделы иерархически организовывались под большой семёркой к примеру, группа comp.lang.c для обсуждения языка С, и rec.games.board для обсуждения настольных игр. Группа бунтарей, посчитавшая это изменение переворотом, организованным Хребтовой кликой, создали собственное ответвление от иерархии, заглавной директорией которого была alt, и свой параллельный хребет. Туда входили темы, считавшиеся неприличными для большой семёрки к примеру, секс и лёгкие наркотики (alt.sex.pictures), а также всякие причудливые сообщества, которые чем-то не понравились админам (к примеру, alt.gourmand; админы предпочитали безобидную группу rec.food.recipes).

К тому времени ПО, поддерживающее Usenet, расширили за пределы распространения обычного текста, и ввели поддержку двоичных файлов (названных так потому, что они содержали произвольные двоичные цифры). Чаще всего среди файлов были пиратские компьютерные игры, порнографические картинки и фильмы, бутлегерские записи с концертов и другой незаконный материал. Группы в иерархии alt.binaries попали в список самых часто блокируемых на серверах Usenet из-за их сочетания высокой стоимости (картинки и видео отнимали гораздо больше трафика и места для хранения, чем текст) и спорного юридического статуса.

Но, несмотря на всю эту полемику, к концу 1980-х Usenet стал местом, где компьютерные знатоки могли найти между народные сообщества, состоявшие из единомышленников. За один только 1991 год Тим Бернерс-Ли объявил о создании всемирной сети WWW в группе alt.hypertext; Линус Торвальдс попросил оставлять в группе comp.os.minix отзывы о его новом небольшом проекте Linux; Питер Адкисон, благодаря рассказу о своей игровой компании, который он запостил в группу rec.games.design, познакомился с Ричардом Гарфилдом. Их совместная работа привела к созданию популярной карточной игры Magic: The Gathering.

FidoNet


Однако несмотря на то, что ARPANET для бедных постепенно расползался по всему земному шару, любители микрокомпьютеров, ресурсов у которых было гораздо меньше, чем у самого захудалого колледжа, в основном были отрезаны от электронных коммуникаций. ОС Unix, которая по стандартам академических учреждений была дешёвым и сердитым вариантом, была недоступной для владельцев компьютеров с 8-битными микропроцессорами, на которых работала ОС CP/M, мало на что способная, кроме как на обеспечение работы с накопителями. Однако вскоре они начали свой собственный простейший эксперимент по созданию очень дешёвой децентрализованной сети, и началось всё с создания досок объявлений bulletin boards.

Возможно, что из-за простоты идеи и огромного количества любителей компьютеров, существовавших в то время, электронную доску объявлений (BBS) могли изобрести несколько раз. Но по традиции, первенство признаётся за проектом Ворда Кристенсена и Рэнди Сьюесса из Чикаго, который они запустили во время затяжной метели 1978 года. Кристенсен и Сьюесс были любителями компьютеров, обоим было по 30 с чем-то лет, и оба ходили в местный компьютерный клуб. Они уже давно планировали создать в компьютерном клубе собственный сервер, куда члены клуба могли бы загружать новостные статьи при помощи ПО для передачи файлов по модему, которое Кристенсен написал для CP/M домашний эквивалент uucp. Но метель, задержавшая их дома на несколько дней, дала им необходимый стимул для того, чтобы начать над ним работу. Кристенсен в основном занимался ПО, а Сьюесс железом. В частности, Сьюесс разработал схему, автоматически перезагружавшую компьютер в режим с запущенной программы BBS каждый раз, когда он обнаруживал входящий звонок. Этот хак был необходим для того, чтобы система гарантированно находилась в подходящем состоянии для приёма этого звонка таково было шаткое состояние домашнего железа и ПО в те времена. Своё изобретение они назвали CBBS, компьютеризованной доской объявлений, однако позже большинство системных операторов (или сисопов) опускали для краткости С, и называли свой сервис просто BBS. В первое время BBS также называли RCP/M, то есть удалёнными CP/M (remote CP/M). Подробности своего детища они описали в популярном журнале для компьютерщиков Byte, и вскоре за ними последовала толпа имитаторов.

Удобрило цветущую сцену BBS новое устройство Hayes Modem. Деннис Хайес был ещё одним любителем компьютеров, и ему очень хотелось подключить к своей новой машине модем. Но существовавшие в продаже коммерческие экземпляры попадали всего в две категории: устройства, предназначенные для бизнес-покупателей, и, следовательно, слишком дорогие для домашних любителей, и модемы с акустической связью. Чтобы связаться с кем-либо по акустическому модему, сначала нужно было дозвониться кому-то по телефону или ответить на вызов, а потом положить на модем трубку так, чтобы он мог общаться с модемом на другом конце. Автоматизировать исходящий или входящий звонок таким образом не представлялось возможным. Поэтому в 1977 году Хайес разработал, сделал и начал продавать собственный модем с передачей данных со скоростью 300 бит в секунду, который можно было вставлять внутрь своего компьютера. В своей BBS Кристенсен и Сьюесс использовали одну из этих ранних моделей хайесовского модема. Однако первым прорывным продуктом Хайеса оказался Smartmodem 1981 года, поставлявшийся в отдельном корпусе, с собственным микропроцессором, и соединявшимся с компьютером по последовательному порту. Продавался он по $299, что было вполне доступно любителям, обычно тратившим на свои домашние компьютеры по несколько сотен долларов.


Hayes Smartmodem на 300 бод

Одним из них был Том Дженнингс, и именно он запустил проект, который стал чем-то вроде Usenet для BBS. Он работал программистом в компании Phoenix Software в Сан-Франциско, и в 1983 году решил написать собственную программу для BBS, только не для CP/M, а для самой новой и лучшей Ос для микрокомпьютеров Microsoft DOS. Назвал он её Fido [типичное имя для собаки], в честь компьютера, который он использовал на работе, названного так потому, что он состоял из жуткой мешанины разных комплектующих. Джон Мэдил, продавец из компании ComputerLand в Балтиморе, узнал о Fido и позвонил Дженнингсу через всю страну, чтобы попросить его помочь так изменить его программу, чтобы она запускалась на его компьютере DEC Rainbow 100. Эта парочка начала совместно работать над ПО, а затем к ним присоединился ещё один любитель Rainbow, Бен Бейкер из Сент-Луиса. Троица потратила значительное количество денег на междугородные звонки, пока они заходили на машины друг друга по ночам, чтобы поболтать в чатах.

В процессе всех этих переговоров на разных BBS в голове у Дженнингса начала зарождаться идея он мог создать целую сеть из BBS, которые обменивались бы сообщениями по ночам, когда стоимость междугородней связи была небольшой. Эта идея не была новой многие любители представляли себе такую передачу сообщений между BBS, ещё со времён появления статьи Кристенсена и Сьюесса в Byte. Однако они обычно предполагали, что для того, чтобы эта схема заработала, нужно сначала достичь очень высокой плотности BBS и построить сложные правила маршрутизации, чтобы все звонки оставались местными, то есть, недорогими, даже когда при передаче сообщений от одного побережья к другому. Однако Дженнингс провёл быстрые расчёты и понял, что при увеличившейся скорости модемов (любительские модемы работали уже на скорости 1200 бит/сек) и уменьшающихся междугородних тарифах такие хитрости были уже не нужны. Даже при значительном увеличении трафика сообщений можно было передавать тексты между системами, тратя всего по несколько баксов за ночь.


Том Дженнингс, кадр из документального фильма 2002 года

Тогда он добавил к Fido ещё одну программу. С часу до двух ночи Fido закрывалась и запускалась FidoNet. Она проверяла список исходящих сообщений в файле со списком узлов. У каждого исходящего сообщения был номер узла, а каждый элемент списка обозначал узел сети Fido BBS у которого рядом был указан телефонный номер. Если исходящие сообщения находились, FidoNet по очереди набирала телефоны соответствующих BBS из списка узлов и передавала их программе FidoNet, ожидавшей звонка с той стороны. Внезапно у Мэдилла, Дженнингса и Бейкера появилась возможность легко и просто совместно работать, хотя и ценой задержки реакции. Они не получали сообщений днём, передача сообщений шла по ночам.

До этого любители редко связывались с другими любителями, жившими в другой местности, поскольку в основном звонили на местные BBS бесплатно. Но если эта BBS была соединена с FidoNet, то пользователи внезапно получали возможность обмениваться электронными письмами с другими людьми по всей стране. Схема сразу оказалась невероятно популярной, и количество пользователей FidoNet начало быстро расти, и за год достигло 200. В связи с этим у Дженнингса всё хуже и хуже получалось обслуживать собственный узел. Поэтому во время первой встречи FidoCon, прошедшей в Сент-Луисе, Дженнингс и Бейкер встретились с Кеном Капланом, ещё одним фанатом DEC Rainbow, который вскоре взял на себя одну из важных ролей в руководстве FidoNet. Они придумали новую схему, делящую Северную Америку на подсети, каждая из которых состоит из местных узлов. В каждой из подсетей один административный узел брал на себя ответственность по управлению местным списком узлов, принимал входящий трафик для своей подсети, и передавал сообщения соответствующим местным узлам. Над слоем подсетей были зоны, покрывавшие весь континент. При этом система всё ещё поддерживала один глобальный список узлов, содержавший телефонные номера всех подключённых к FidoNet компьютеров в мире, поэтому теоретически любой узел мог напрямую позвонить на любой другой для доставки сообщений.

Новая архитектура позволила системе продолжать расти, и к 1986 году она увеличилась до 1000 узлов, а к 1989 до 5000. У каждого из этих узлов (который представлял собой BBS) было в среднем по 100 активных пользователей. Два самых популярных приложения были простейший обмен почтой, который Дженнингс встроил в FidoNet, и Echomail, созданный Джеффом Рашем, сисопом BBS из Далласа. Echomail был функциональным эквивалентом новостных групп Usenet, и позволял тысячам пользователей FidoNet вести публичные обсуждения на различные темы. Эхи, как называли отдельные группы, имели одиночные названия, в отличие от иерархичной системы Usenet, от AD&D до MILHISTORY и ZYMURGY (изготовление пива в домашних условиях).

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

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

Однако как и в случае с Usenet, иерархическая структура FidoNet дала возможность некоторым сисопам получить больше власти, чем было у других, и поползли слухи о появлении могущественной клики (на этот раз базирующейся в Сент-Луисе), которая хочет забрать у людей управление сетью. Многие боялись, что Каплан или другие люди из его окружения попытаются коммерциализировать систему и начнут брать деньги за использование FidoNet. Особенно сильные подозрения возникали по поводу International FidoNet Association (IFNA), некоммерческой ассоциации, которую основал Каплан для того, чтобы оплатить часть стоимости обслуживания системы (особенно междугородные звонки). В 1989 году казалось, что эти подозрения реализовались, когда группа лидеров IFNA продавила референдум за то, чтобы сделать каждого сисопа FidoNet членом IFNA, и сделать ассоциацию официальной организацией, управляющей сетью, и отвечающей за все её правила и нормы. Идея провалилась, и IFNA исчезла. Конечно, отсутствие символической управляющей структуры не означало, что в сети нет реальной власти; администраторы региональных списков узлов вводили свои произвольные правила.

Тень интернета


С конца 1980-х и далее FidoNet и Usenet постепенно начала затмевать тень интернета. Ко второй половине следующего десятилетия они были полностью поглощены ею.

Usenet переплелась с веб-сайтами интернета благодаря созданию протокола NNTP сетевого протокола передачи новостей в начале 1986. Его задумала парочка студентов Калифорнийского университета (один из филиала в Сан-Диего, другой из Беркли). NNTP позволял узлам сети TCP/IP в интернете создавать новостные серверы, совместимые с Usenet. За несколько лет большая часть трафика Usenet уже шла через эти узлы, а не через uucp по старой доброй телефонной сети. Независимая сеть uucp постепенно зачахла, а Usenet стала очередным приложением, работающим поверх TCP/IP. Невероятная гибкость многослойной архитектуры интернета с лёгкостью позволяла ему поглощать сети, приспособленные для единственного приложения.

Хотя в начале 1990-х между FidoNet и интернетом существовало несколько шлюзов, позволявших сетям обмениваться сообщениями, FidoNet не была единственным приложением, поэтому её трафик не мигрировал в интернет так, как это произошло с Usenet. Вместо этого, когда люди вне академических кругов впервые начали изучать доступ в интернет во второй половине 1990-х, BBS постепенно либо поглощались интернетом, либо становились ненужными. Коммерческие BBS постепенно попали в первую категорию. Такие мини-копии CompuServes предлагали доступ к BBS за ежемесячную плату тысячам пользователей, и у них было несколько модемов для приёма нескольких входящих вызовов одновременно. С появлением коммерческого доступа в интернет эти предприятия подсоединили свои BBS к ближайшей части интернета и начали предлагать доступ к нему своим клиентам в рамках подписки. Чем больше сайтов и сервисов появлялось в расцветающей всемирной паутине, тем меньше пользователей подписывались на услуги конкретных BBS, и поэтому эти коммерческие BBS постепенно превратились в простых провайдеров интернета, ISP. Большая часть любительских BBS превратилась в города-призраки, поскольку пользователи, желавшие выйти в интернет, перешли к местным провайдерам, а также к филиалам более крупных организаций типа America Online.

Всё это прекрасно, но каким образом интернет занял такую доминирующую позицию? Как малоизвестная академическая система, годами распространявшаяся по элитным университетам, в то время как такие системы, как Minitel, CompuServe и Usenet привлекали миллионы пользователей, вдруг вырвалась на передний план и распространилась как сорняк, поглотив всё, что было до неё? Как интернет стал силой, завершившей эру фрагментации?

Что ещё почитать и посмотреть


  • Ronda Hauben and Michael Hauben, Netizens: On the History and Impact of Usenet and the Internet, (online 1994, print 1997)
  • Howard Rheingold, The Virtual Community (1993)
  • Peter H. Salus, Casting the Net (1995)
  • Jason Scott, BBS: The Documentary (2005)
Подробнее..

Категории

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

© 2006-2020, personeltest.ru