Моменты перепланирования использования ЦП не могут быть связаны с событиями

Обновлено: 21.11.2024

TL;DR: масштабирование модулей и узлов в кластере Kubernetes с настройками по умолчанию может занять несколько минут. Узнайте, как определить размер узлов кластера, настроить горизонтальное автомасштабирование и автомасштабирование кластера, а также выделить ресурсы кластера для более быстрого масштабирования.

Содержание:

В Kubernetes несколько вещей называются "автомасштабированием", в том числе:

Эти инструменты автомасштабирования относятся к разным категориям, потому что они решают другие проблемы.

Горизонтальное автомасштабирование Pod (HPA) предназначено для увеличения числа реплик в ваших развертываниях.

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

Горизонтальное автомасштабирование Pod (HPA) регулярно проверяет такие показатели, как память и ЦП.

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

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

Например, вы не можете масштабировать базу данных (легко), только добавляя дополнительные модули.

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

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

Именно в этом и заключается цель вертикального автомасштабирования — увеличение размера модуля.

Вы не можете увеличить количество реплик только для масштабирования базы данных в Kubernetes.

Но вы можете создать модуль с более крупными ресурсами. Вертикальное автомасштабирование Pod может делать это автоматически.

И наконец, средство автомасштабирования кластера (CA).

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

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

При масштабировании модулей в Kubernetes может не хватить места.

Автомасштабирование кластера предназначено для увеличения количества узлов в вашем кластере.

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

Несмотря на то, что все эти компоненты "автомасштабируют" что-то, они совершенно не связаны друг с другом.

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

И они разрабатываются в отдельных проектах и ​​могут использоваться независимо друг от друга.

Однако масштабирование кластера требует точной настройки параметров автомасштабирования, чтобы они работали согласованно.

Давайте рассмотрим пример.

Когда происходит сбой автомасштабирования пакетов

Представьте себе, что у вас есть приложение, которое постоянно использует 1,5 ГБ памяти и 0,25 ВЦП.

Вы подготовили кластер с одним узлом объемом 8 ГБ и двумя виртуальными ЦП — он должен идеально вместить четыре модуля (и оставить немного дополнительного места).

Вы развертываете один модуль и настраиваете:

  1. Автомасштабирование горизонтального модуля добавляет реплику каждые 10 входящих запросов (т. е. если у вас есть 40 одновременных запросов, оно должно масштабироваться до 4 реплик).
  2. Автомасштабирование кластера для создания дополнительных узлов при нехватке ресурсов.

Автомасштабирование Horizontal Pod может масштабировать реплики в вашем развертывании с помощью специальных показателей, таких как количество запросов в секунду (QPS) от контроллера Ingress.

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

  1. Горизонтальное автомасштабирование модулей начинает масштабирование модулей.
  2. Создаются еще два модуля.
  3. Автомасштабирование кластера не срабатывает — в кластере не создается новый узел.

Это имеет смысл, так как в этом узле достаточно места для еще одного модуля.

Вы увеличиваете трафик до 40 одновременных запросов и снова наблюдаете:

  1. Автомасштабирование горизонтального модуля создает еще один модуль.
  2. Под находится на рассмотрении и не может быть развернут.
  3. Автомасштабирование кластера инициирует создание нового узла.
  4. Подготовка узла занимает 4 минуты. После этого ожидающий модуль развертывается.

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

Мастер автомасштабирования создает новый узел, и наконец модуль развертывается.

Почему четвертый модуль не развернут на первом узле?

Поды, развернутые в вашем кластере Kubernetes, потребляют такие ресурсы, как память, ЦП и хранилище.

Однако на одном узле операционной системе и кублету также требуются память и ЦП.

В рабочем узле Kubernetes память и ЦП делятся на:

  1. Ресурсы, необходимые для запуска операционной системы и системных демонов, таких как SSH, systemd и т. д.
  2. Ресурсы, необходимые для запуска агентов Kubernetes, таких как Kubelet, среда выполнения контейнера, детектор проблем узла и т. д.
  3. Ресурсы, доступные для модулей.
  4. Ресурсы зарезервированы до порога исключения.

Как вы можете догадаться, все эти квоты можно настраивать, но вам необходимо учитывать их.

В виртуальной машине с 8 ГБ и 2 ВЦП вы можете ожидать:

  • 100 МБ памяти и 0,1 ВЦП должны быть зарезервированы для операционной системы.
  • 1,8 ГБ памяти и 0,07 ВЦП будут зарезервированы для Kubelet.
  • 100 МБ памяти для порога вытеснения.

Остальные ~6 ГБ памяти и 1,83 ВЦП могут использоваться модулями.

Если в вашем кластере работает DeamonSet, такой как kube-proxy, вам следует дополнительно уменьшить доступную память и ЦП.

Учитывая, что kube-proxy имеет запросы на 128 МБ и 0,1 виртуального ЦП, для запуска модулей доступно только ~5,9 ГБ памяти и 1,73 виртуального ЦП.

Запуск CNI, такого как Flannel, и сборщика журналов, такого как Fluentd, еще больше сократит использование ресурсов.

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

Четвертый вариант остается в состоянии ожидания, если его нельзя развернуть на другом узле.

Поскольку Cluster Autoscaler знает, что для четвертого модуля нет места, почему он не выделяет новый узел?

Почему он ждет, пока модуль будет ожидать обработки, прежде чем инициировать создание узла?

Как работает Cluster Autoscaler в Kubernetes

Автомасштабирование кластера не учитывает доступную память или ЦП при запуске автомасштабирования.

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

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

Например, если модуль запрашивает 1 виртуальный ЦП, но в кластере доступно только 0,5 виртуального ЦП, планировщик помечает модуль как незапланированный.

Именно тогда средство автомасштабирования кластера инициирует создание нового узла.

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

  • Случайный выбор типа узла случайным образом. Это стратегия по умолчанию.
  • Большинство модулей — выбирает группу узлов, которая будет запланировать наибольшее количество модулей.
  • Наименьшие потери: после масштабирования выбирается группа узлов с наименьшим количеством простаивающих ЦП.
  • Цена — выберите группу узлов, которая будет стоить меньше всего (в настоящее время работает только для GCP).
  • Приоритет — выбирает группу узлов с наивысшим приоритетом (и вы назначаете приоритеты вручную).

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

Если вы используете AWS, Cluster Autoscaler предоставит новый экземпляр EC2.

В Azure будет создана новая виртуальная машина, а в GCP — новый вычислительный движок.

Может пройти некоторое время, прежде чем созданные узлы появятся в Kubernetes.

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

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

Инициализация нового вычислительного блока может занять несколько минут.

Но давайте углубимся в цифры.

Изучение времени выполнения автоматического масштабирования пакета

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

  1. Время отклика Horizontal Pod Autoscaler.
  2. Время реакции средства автомасштабирования кластера.
  3. Время подготовки узла.
  4. Время создания пакета.

Контроллер Horizontal Pod Autoscaler отвечает за проверку метрик и принятие решений об увеличении или уменьшении масштаба ваших реплик.

В худшем случае автомасштабирование горизонтального модуля может занять до полутора минут, чтобы запустить автомасштабирование (т. е. 10 + 60 + 15 секунд).

Как только один или несколько модулей будут обнаружены, будет запущен алгоритм для принятия решения:

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

Весь процесс должен занять:

  • Не более 30 секунд в кластерах, содержащих менее 100 узлов и до 30 модулей в каждом. Средняя задержка должна составлять около 5 секунд.
  • Не более 60 секунд в кластере с числом узлов от 100 до 1000. Средняя задержка должна составлять около 15 секунд.

Затем следует время подготовки узла, которое в основном зависит от поставщика облачных услуг.

Обычно новый вычислительный ресурс выделяется за 3–5 минут.

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

Запуск контейнера не должен занимать более нескольких миллисекунд, но загрузка образа контейнера может занять несколько секунд.

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

Таким образом, общее время запуска автоматического масштабирования при отсутствии места в текущем кластере составляет:

  1. Горизонтальное автомасштабирование Pod может занять до 1 минуты 30 секунд, чтобы увеличить количество реплик.
  2. Автомасштабирование кластера должно занимать менее 30 секунд для кластера с менее чем 100 узлами и менее минуты для кластера с более чем 100 узлами.
  3. Поставщику облачных служб может потребоваться от 3 до 5 минут для создания ресурса компьютера.
  4. Во время выполнения контейнера загрузка образа контейнера может занять до 30 секунд.

В худшем случае с небольшим кластером у вас есть:

В кластере с более чем 100 узлами общая задержка может достигать 7 минут.

Вы согласны ждать 7 минут, прежде чем у вас появится больше модулей, чтобы справиться с внезапным всплеском трафика?

Как настроить автомасштабирование, чтобы сократить время масштабирования, которое составляет 7 минут, если вам нужен новый узел?

Вы можете изменить:

  • Время обновления для горизонтального автомасштабирования Pod (управляется флагом --horizontal-pod-autoscaler-sync-period, по умолчанию – 15 секунд).
  • Интервал для извлечения метрик на сервере метрик (управляется флагом разрешения метрик, по умолчанию 60 секунд).
  • Как часто средство автомасштабирования кластера сканирует незапланированные модули (управляется флагом интервала сканирования, по умолчанию 10 секунд).
  • Как вы кэшируете изображение на локальном узле (с помощью такого инструмента, как kube-fledged).

Но даже если вы настроите эти параметры на крошечное число, вы все равно будете ограничены временем подготовки облачного провайдера.

Итак, как вы можете это исправить?

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

Можно попробовать две вещи:

  1. По возможности не создавайте новые узлы.
  2. Упреждающее создание узлов, чтобы они были подготовлены к моменту, когда они вам понадобятся.

Давайте рассмотрим варианты по одному.

Выбор оптимального размера экземпляра для узла Kubernetes

Выбор правильного типа экземпляра для вашего кластера имеет серьезные последствия для вашей стратегии масштабирования.

Рассмотрите следующий сценарий.

У вас есть приложение, которое запрашивает 1 ГБ памяти и 0,1 виртуального ЦП.

Вы выделяете узел с 4 ГБ памяти и 1 виртуальным ЦП.

После резервирования памяти и ЦП для kubelet, операционной системы и порога вытеснения у вас остается ~2,5 ГБ памяти и 0,7 ВЦП, которые можно использовать для запуска модулей.

На вашем узле есть место только для двух модулей.

Каждый раз, когда вы масштабируете свои реплики, вы, вероятно, столкнетесь с задержкой до 7 минут (время подготовки к запуску автоматического масштабирования Horizontal Pod, автомасштабирования кластера и подготовке вычислительных ресурсов у облачного провайдера).

Давайте посмотрим, что произойдет, если вместо этого вы решите использовать 64 ГБ памяти и 16 виртуальных ЦП.

После резервирования памяти и ЦП для kubelet, операционной системы и порога исключения у вас остается ~58,32 ГБ памяти и 15,8 ВЦП, которые можно использовать для запуска модулей.

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

Кроме того, при каждом добавлении узла в кластер можно развернуть несколько модулей.

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

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

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

Посмотрите на этот график, на котором показана память, доступная для модулей.

По мере увеличения размера экземпляра вы можете заметить, что (пропорционально) увеличиваются ресурсы, доступные модулям.

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

Стоит ли всегда выбирать самый большой экземпляр?

Пик эффективности зависит от того, сколько модулей Pod может быть на узле.

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

И выбор более крупного типа экземпляра не всегда является хорошим вариантом.

Вы также должны учитывать:

  1. Радиус взрыва: если у вас всего несколько узлов, то влияние неисправного узла больше, чем если у вас много узлов.
  2. Автомасштабирование менее рентабельно, поскольку следующим шагом является (очень) большой узел.

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

Как это обойти?

Что, если вместо создания нового узла при масштабировании вы создадите тот же узел заранее?

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

Если вы можете позволить себе постоянно иметь запасной узел, вы можете:

  1. Создайте узел и оставьте его пустым.
  2. Как только в пустом узле появляется под, вы создаете еще один пустой узел.

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

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

Как только на пустом узле создается модуль, средство автомасштабирования кластера создает новый узел.

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

Это компромисс: вы несете дополнительные расходы (одна пустая вычислительная единица доступна всегда), но вы выигрываете в скорости.

С помощью этой стратегии вы сможете намного быстрее масштабировать свой парк.

Но есть и плохие, и хорошие новости.

Плохая новость заключается в том, что Cluster Autoscaler не имеет встроенной функции.

Его нельзя настроить как упреждающее, и нет флага "всегда подготавливать пустой узел".

Хорошая новость заключается в том, что вы все еще можете притворяться.

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

Вы можете рассматривать этот модуль как заполнитель — он предназначен для резервирования места, а не для использования каких-либо ресурсов.

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

Китай: пользователи, находящиеся в Китае, не смогут настраивать или посещать прямые трансляции Microsoft Stream, Microsoft Teams или Yammer, а также просматривать видео по запросу, поскольку в настоящее время Azure CDN, на который опираются эти приложения, может быть недоступна. в Китае.

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

Убедитесь, что все конечные точки в вашей сети доступны

Общие конечные точки Microsoft Stream (Classic)

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

Внешнее приложение или устройство, создающее прямые трансляции (ранее — внешний кодировщик) — конечные точки загрузки RMTP

Чтобы получить видеопоток для события прямой трансляции, созданного внешним приложением или устройством, отправленного в Microsoft Stream (Classic) с вашего кодировщика, вам потребуются следующие диапазоны IP-адресов и порты, открытые в брандмауэре вашей сети:

Если ваша конкретная настройка сети не позволяет (или вы не хотите) открывать указанный выше диапазон доменов, в настоящее время единственный способ получить определенные IP-адреса для загрузки RTMP/RTMPS — это получить меняющиеся диапазоны IP-адресов для центра обработки данных Azure, к которому подключен ваш клиент Microsoft Stream (Classic).

Следующие файлы JSON обновляются по мере изменения IP-адресов центров обработки данных Azure с разбивкой по регионам и службам с тегами.

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

Чтобы найти центр обработки данных Azure для арендатора Stream (Classic):

В потоке нажмите ? в правом верхнем углу.

Выберите О Microsoft Stream.

Просмотреть информацию в разделе Ваши данные хранятся в.

После того, как вы найдете центр обработки данных Azure для своего клиента Stream (Classic), найдите соответствующие диапазоны IP-адресов в XML-файле выше, а затем обновите свой брандмауэр/прокси-сервер, указав конкретные диапазоны IP-адресов для вашего центра обработки данных. По мере изменения XML-файла вам также потребуется обновить настройки брандмауэра/прокси-сервера.

Если в разделе «О Microsoft Stream» указано, что ваши данные хранятся в «Восточной части США 2»

В файле XML вы должны искать узел с меткой

В этом узле "Регион" будет несколько записей для всех диапазонов IP-адресов ( )

Вам потребуется настроить брандмауэр\прокси-сервер, чтобы разрешить все эти диапазоны IP-адресов, и регулярно менять их при изменении XML-файла.

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

Убедитесь, что у вас достаточно пропускной способности для загрузки

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

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

Если у вас есть проблемы с пропускной способностью загрузки, вот несколько вещей, которые вы можете попробовать:

Используйте проводное подключение к сети Ethernet для любого компьютера, с которого вы передаете поток, чтобы избежать перебоев в сети Wi-Fi.

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

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

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

Настройте существующие прокси-серверы кэширования в вашей сети для кэширования видео из Microsoft Stream.

Используйте стороннее решение для доставки видео eCDN для оптимизации видеотрафика.

Я не могу создать прямую трансляцию

В Microsoft Stream, Yammer и Microsoft Teams существуют разрешения, необходимые пользователю для создания трансляции, в зависимости от того, какую службу вы используете для трансляции.

Убедитесь, что администратор Microsoft Stream (Classic) разрешил вам создавать прямые трансляции. Узнать больше

Уточните у администратора, есть ли у вас действующая лицензия Microsoft Stream (Classic), позволяющая создавать прямые трансляции.

Майкрософт 365

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

Пользователь должен быть администратором группы Yammer.

Если пользователь собирается создавать события "внешнее приложение или устройство", ему необходимо разрешение на создание прямых трансляций в Microsoft Stream.

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

Как сделать так, чтобы моя трансляция отображалась в Yammer?

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

Как сделать так, чтобы моя трансляция отображалась в Microsoft Stream?

Если вы хотите, чтобы ваше мероприятие отображалось в Microsoft Stream (Classic), вы можете:

  • Создайте прямую трансляцию, начиная с Stream.
  • Выберите «внешнее приложение или устройство» в качестве типа события при его создании для Yammer/Microsoft Teams.

Как сделать так, чтобы моя трансляция отображалась в Microsoft Teams?

Если вы хотите, чтобы ваше мероприятие отображалось в Microsoft Teams, вы можете создать свое мероприятие либо в Yammer, либо в Microsoft Teams. Для получения дополнительной информации см. сравнение функций по службам и типам событий.

Почему я не могу редактировать прямую трансляцию в Microsoft Stream?

Если вы создали трансляцию из Yammer или Microsoft Teams и выбрали в качестве типа "внешнее приложение или устройство", то это событие отображается в Microsoft Stream. Однако до тех пор, пока событие не будет завершено, вы можете вносить изменения в событие (название, разрешения, дату/время), редактируя событие в Microsoft Teams. Это связано с тем, что в течение этого периода информация о трансляции поступает из связанного с ней события Microsoft Teams.

Убедитесь, что у зрителей есть разрешение на просмотр мероприятия

Яммер

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

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

Команды Майкрософт

Прямые трансляции из Microsoft Teams имеют несколько разных ролей для разрешений на само мероприятие (Организатор, Продюсер, Ведущий, Участник).

Microsoft Stream (классический)

Если ваше мероприятие в прямом эфире началось в Yammer или Microsoft Teams, то разрешения для мероприятия в прямом эфире до и во время мероприятия берутся из мероприятия в Microsoft Teams.

Если трансляция была создана непосредственно в Stream, разрешения можно установить в Stream. Владельцы могут редактировать/создавать мероприятие, а зрители смогут просто смотреть его.

Общую информацию о разрешениях в Microsoft Stream см. в разделе Разрешения и конфиденциальность.

Создание прямого эфира

Я не знаю, как настроить кодировщик

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

Мой кодировщик не подключается к URL-адресу загрузки сервера

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

Убедитесь, что URL-адрес RTMP(S) правильно введен в качестве выходных данных вашего кодировщика.

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

Проверьте состояние вашего интернет-соединения, чтобы убедиться, что кодировщик правильно подключен и находится в сети.

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

Возможно, ваш кодировщик не поддерживается Microsoft Stream. Ознакомьтесь со списком протестированных кодировщиков.

Кажется, я не могу заставить RTMPS работать

  1. Некоторые кодировщики могут поддерживать другую реализацию, не поддерживаемую Microsoft Stream. Ознакомьтесь со списком протестированных кодировщиков, которые работают с Microsoft Stream.
  2. Не все кодировщики или версии поддерживают RTMPS. Узнайте у производителя или создателя программного обеспечения, что они поддерживают.

Я попытался начать настройку, но это заняло много времени

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

Я попытался начать настройку, но происходит слишком много событий

Если достигнуто максимальное количество одновременных активных событий, администратор Microsoft Stream (Classic) может остановить другие события, чтобы освободить место для события с более высоким приоритетом. Ознакомьтесь с элементами управления администрированием прямых трансляций.

Я не вижу превью продюсера

  1. После начала потоковой передачи с кодировщика может пройти около 30 секунд, прежде чем появится предварительный просмотр продюсера.
  2. Убедитесь, что кодировщик подключен к Microsoft Stream.
  3. Иногда может помочь обновление страницы в Microsoft Stream. Вас могут спросить, хотите ли вы покинуть страницу; это не повлияет на вашу прямую трансляцию.
  4. Некоторые сети могут блокировать доступ к контенту. Убедитесь, что настройки сетевой безопасности и брандмауэра разрешают протокол RTMP(S), а необходимые домены находятся в списке разрешенных. Попробуйте проверить, работает ли он в другом сетевом окружении, независимо от корпоративной сети, VPN или заблокированной сети.

Моя лента выглядит плохо, плохого качества или глючит

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

Убедитесь, что вы используете рекомендуемые параметры кодировщика для Microsoft Stream. Дополнительную информацию см. в разделе Настройка кодировщиков для прямой трансляции.

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

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

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

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

Я запустил прямую трансляцию, но не подключил кодировщики

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

Я завершил трансляцию с кодировщика, но зрители видят ошибку

Выберите Остановить событие перед отключением кодировщика. Если вы уже отключили видеокодер, вы все равно можете нажать "Остановить событие", но зрители могут увидеть ошибку.

Мои зрители видят проблемы

  1. Если один зритель сообщает о проблеме, убедитесь, что он имеет достаточную пропускную способность и хорошее подключение к Интернету для просмотра события.
  2. Если проблемы возникли у нескольких пользователей в одной сети, возможно, у вас возникли проблемы, связанные с перегрузкой сети. Узнайте больше о eCDN как об одном из возможных решений этой проблемы.
  3. Часто, когда несколько зрителей видят проблему, она на самом деле связана с фидом кодировщика.
    • Убедитесь, что кодировщик правильно настроен в соответствии со спецификациями, указанными в настройках кодировщика, и правильно настроен.
    • Убедитесь, что пропускная способность загрузки достаточна для потоковой передачи. Вы можете попробовать уменьшить полосу пропускания на выходе кодировщика.
    • Иногда помогает сброс кодировщика, но учтите, что при повторном подключении необходимо сохранить те же настройки. Зрители могут увидеть ошибку или сбой в трансляции.

Чтобы узнать о других распространенных ошибках воспроизведения при предварительном просмотре или о том, как сообщить о проблеме, см. раздел Общие сведения об ошибках воспроизведения.

Я или мои зрители не слышу видео

  1. Убедитесь, что кодировщик отправляет звук.
  2. Убедитесь, что аудиоустройство подключено.
  3. В Windows убедитесь, что выбрано правильное звуковое устройство и включен звук.
  4. Если вы используете Internet Explorer 11 и не можете включить звук проигрывателя, откройте "Настройки" > "Свойства обозревателя" > "Дополнительно", затем прокрутите до раздела "Мультимедиа" и убедитесь, что выбран параметр "Воспроизводить звуки на веб-страницах".

    5. Приложения и службы Microsoft 365 не будут поддерживать Internet Explorer 11 с 17 августа 2021 г. (Microsoft Teams не будет поддерживать Internet Explorer 11 ранее, начиная с 30 ноября 2020 г.). Узнать больше. Обратите внимание, что Internet Explorer 11 останется поддерживаемым браузером. Internet Explorer 11 является компонентом операционной системы Windows и следует политике жизненного цикла продукта, на котором он установлен. Microsoft Stream (Classic) поддерживает Microsoft Edge и текущие версии Chrome и Safari.

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

    Мне нужна дополнительная помощь в настройке прямой трансляции

    Вы можете воспользоваться общедоступной предварительной версией программы Microsoft 365 Live Events Assistance. Его цель — помочь клиентам пройти первое живое мероприятие, а также оказать помощь в предстоящем живом мероприятии. Дополнительную информацию см. в документации по сопровождению прямых трансляций.

    Через несколько секунд он перестал печатать x в вымысле. Я намеренно использую 1 процессор, чтобы понять, почему он останавливается. Планировщик застрял и больше не перепланирует горутину, запускающую выдумку?

    @icza Я думаю, что это не проблема «Когда заканчивается основная горутина, ваше приложение также завершается», я запускал код с помощью трассировщика времени выполнения, похоже, проблема в планировщике golang с fmt. Println никогда не перепланирует счетчик через несколько вызовы fib могут быть связаны (я вполне могу ошибаться), но планировщик go является частично упреждающим, а не полностью. Кроме того, алгоритм fib имеет экспоненциальную сложность, поэтому вызов fib не будет возвращен так рано.

    @GauravDhiman Да, верно. Планирование горутин «не в ваших руках» без явной синхронизации, spinner() имеет цикл занятости, а планировщик горутин никогда не переключается обратно на основную горутину.

    @gaurav-dhiman, в Go ≤ 1.13 это вообще не упреждающее действие. 1.14 должен быть первым релизом, когда он будет «почти» упреждающим, и проблема тугих петель должна быть решена.

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

    @JimB: за исключением того, что иногда вам нужно это делать (и 100% загрузка процессора не является проблемой). Я надеюсь, что они оставят нам этот вариант.

    1 Ответ 1

    Планировщик застрял и больше не перепланирует горутину, запускающую выдумку?

    Короткий ответ: да.

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

    Как отмечает ДжимБи в комментарии, тип жесткого цикла вращения, который у вас есть в счетчике, — это . недружелюбно, в лучшем случае. Он должен содержать какой-то метод высвобождения вычислительных ресурсов, такой как вращение с time.After или time.NewTicker, или, по крайней мере, вызов runtime.Gosched().Я предполагаю, что ваш оригинальный счетчик был чем-то вроде этого, только без времени. NewTicker :

    (Я изменил тип возвращаемого значения на int64 по очевидным причинам.) Теперь мы можем найти Fibonacci(90) = 2880067194370816120 за 0,00 секунды (с округлением).

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

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

    Содержание

    Оценить причину отмены или переноса мероприятия

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

    Внутренние и внешние факторы

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

    Отложить или отменить?

    Последствия переноса и отмены мероприятия

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

    Привлечет ли наше отложенное мероприятие столько же регистраций, сколько и исходное мероприятие?

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

    Будет ли наш зал доступен в перенесенную дату?

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

    Как мы будем привлекать потенциальных клиентов после отмены нашего мероприятия?

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

    Повлияет ли отмена на имидж нашего бренда?

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

    Рекомендации по переносу и отмене мероприятий

    Прозрачность

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

    Возврат средств подтвержденным регистрантам

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

    Будьте доступны для вопросов

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

    Отправить контент

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

    Страхование отмены мероприятия

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

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

    1. Травма участника
    2. Ущерб объекту
    3. Судебные иски участников
    4. Ответственность за алкоголь
    5. Отмена мероприятия

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

    Рекомендации по информированию об отмене и переносе мероприятий

    Push-уведомления для мобильных приложений

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

    Создать страницу часто задаваемых вопросов

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

    Почаще обновляйте список участников

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

    Будьте очень конкретными

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

    Используйте отмену и перенос событий как возможность

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

    Анна Линтикум

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

    Читайте также: