Содержание

что это такое простыми словами, SMM- маркетинг и реклама

SMM (Social Media Marketing) был и остается в 2020 году генератором клиентопотока для большинства тематик в бизнесе. Заниматься маркетингом в социальных сетях сегодня, значит быть рядом с клиентом. Это совершенно легальный способ стать тем, что человек увидит первым делом утром, когда возьмет телефон в руки и последним, когда он ложится спать.

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

Что такое смм продвижение в социальных сетях

SMM это комплекс мероприятий в социальных сетях, блогах и иных интернет-ресурсах, направленных на продвижение товаров или услуг. Цель у маркетинговых активностей в социальных сетях, как и в обычном маркетинге — продажи.

С помощью социальных медиа очень хорошо продвигаются такие бизнесы, как:

  • Одежда, обувь и аксессуары к ним.
  • Изделия ручной работы и сувениры.
  • Товары сектора B2C.
  • Курсы и мероприятия.
  • Товары и услуги бьюти-сферы.
  • Частные специалисты (не ситуативные).

Несколько сложнее продвигать в социальных сетях такие тематики, как:

  • Строительство.
  • Покупки жилья или авто.
  • Ситуативные бизнесы.
  • Бизнесы, которые сильно привязаны к локации и их основной клиентопоток идет из проходящего мимо них трафика.
  • Сектор B2B весьма сложен в продвижении с помощью социальных сетей.

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

  • В подарок кому-либо.
  • Чтобы порадовать себя новым предметом интерьера/гардероба и прочее.

Это покупки, основанные на эмоциях.

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

Главные принципы успеха

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

Главные принципы успеха продвижения в данном каналу таковы:

  • Стратегия — первостепенна.
  • Визуальная привлекательность вашей страницы компании или личного профиля сильно влияет на конверсию.
  • Будьте честны и открыты в общении с аудиторией.
  • Будьте на виду и генерируйте качественный контент.
  • Реклама — двигатель торговли.

А теперь, обо всем по порядку.

Стратегия в смм

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

Ниже мы приводим данные, которые вам понадобятся, чтобы прописать вашу стратегию:

  • Текущее положение дел: есть соцсети или нет, число подписчиков, актуальность дизайна, качество контента, репутация в сети и прочее.
  • Данные анализа конкурентов.
  • Прописанные портреты потребителя.
  • Ваше УТП.
  • Формат присутствия в соцсетях.
Формат присутствия

Выделяют всего три формата:

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

Графическое оформление групп

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

Основные пункты при создании сообщества компании

  • Нейминг. Название должно быть продумано до мелочей. Логичнее всего следовать следующей формуле: Название товара/услуги + ГЕО + Название вашего бренда. К примеру: “Кроссовки в Москве Sneaker”.
     
  • Уникальный url-адрес сообщества должен соответствовать названию бренда и быть одинаковым во всех соц.сетях.
     
  • Описание сообщества. В инстаграме у вас будет всего несколько строчек для того, чтобы рассказать о своих основных преимуществах перед аналогичными товарами/услугами. Нет смысла писать более объемные тексты в других социальных сетях.

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

  • Обсуждения. Создайте основные темы и поддерживайте актуальность информации в них: отзывы, возможность задать вопрос со своей проблемой, скидки и акции. Данный вариант не подойдет для Instagram. Обратную связь вам периодически придется запрашивать в постах.
     
  • Настройки приватности. Разбираться в данных настройках вам нужно только если вы, к примеру, организуете закрытый vip-клуб для ваших клиентов и требуется закрыть сообщество от посторонних.
     
  • Во Вконтакте и Facebook поддерживается функционал витрины. Там можно добавить товары и услуги в качестве карточек с ценами. Для тех, у кого товарный ассортимент составляет несколько сотен и даже тысяч товаров, есть сервисы для автоматической загрузки товарных позиций.
     
  • Опознавательные знаки. Геометки и фирменные хештеги должны быть созданы и использованы в официальном сообществе, это поможет пользователям находить ваш контент и делиться им в социальных сетях.

Контент-стратегия

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

Последнее — предпочтительнее.

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

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

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

Если у вас не хватает идей или материалов для создания контента, то рекомендуем обращаться к нам. У нас ни со знаниями, ни с креативом проблем нет. Всего в достатке:).

Реклама

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

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

    Разнообразие рекламных форматов и настроек объявлений позволяют по разному контактировать с аудиторией.

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

  • Реклама, купленная в профилях/группах. Еще один формат рекламного размещения. Его отличие — отсутствие централизованности. Вам придется отдельно договариваться с каждым администратором площадки о цене рекламы, времени выхода и прочем.

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

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

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

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

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

Управление репутацией в соцсетях

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

  • Будьте открыты к обращениям целевой аудитории и критике.
  • Реагируйте на каждый из комментариев с упоминанием вашего бренда. И положительные, и отрицательные, и нейтральные. Даже небольшой очаг негатива может превратиться в большой пожар и выйти за пределы вашей зоны контроля. Негатив не стоит игнорировать или удалять. С ним нужно только работать. Попробуйте прикинуть “ущерб”, нанесенный причиной появления негатива и предложите соответствующую компенсацию. Обычно она не обходится слишком дорого.
  • Работайте над ошибками. Исправить мало, гораздо важнее не повторять больше их.

Итог

Теперь вы знаете основы Social Media Marketing, которые выведут ваш бизнес на новый уровень сервиса и близости к клиентам.

100 главных навыков SMM-специалиста. Читайте на Cossa.ru

Social Media Marketing — это не состояние души и не волшебство, SMM-специалистом нельзя стать, набрав 5 000 друзей в Facebook или выступив на паре конференций. Стать профессионалом можно только овладевая определенными инструментами и постоянно прокачивая определенные навыки.

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

Итак, SMM-специалист должен уметь:

Разработка стратегии

1. Определять целевую аудиторию.
2. Исследовать интересы и поведение целевой аудитории.
3. Определять вектора интересов аудитории.
4. Проводить анализ ниши клиента.
5. Разрабатывать аргументарную базу.
6. Подбирать площадки с высокой концентрацией ЦА.
7. Разрабатывать общую стратегию присутствия компании в социальных сетях.
8. Подбирать инструменты, оптимально решающие задачи клиента.
9. Разрабатывать систему KPI.
10. Определять влияние SMM на бизнес клиента.
11. Интегрировать SMM-активности в общую маркетинговую стратегию компании.

Свяжите сервисы между собой без программистов за 5 минут!

Cossa рекомендует использовать ApiX-Drive для самостоятельной интеграции разных сервисов между собой. Доступно 200+ готовых интеграций!

  • Автоматизируйте работу интернет-магазина или лендинга;
  • Расширяйте возможности за счёт интеграций;
  • Не тратьте деньги на программистов и интеграторов;
  • Экономьте время за счёт автоматизации рутинных задач.

Бесплатно протестируйте работу сервиса прямо сейчас и начните экономить до 30% времени! Перейти

Реклама

Social Media Marketing навыки

12. Правильно позиционировать сообщество.
13. Управлять таргетированной рекламой во ВКонтакте.
14. Управлять контекстной рекламой на Facebook.
15. Понимать механизмы рекламы в приложениях ВКонтакте.
16. Прогнозировать бюджет контекстной рекламы.
17. Оптимизировать бюджет контекстной рекламы.
18. Проектировать и проводить конкурсы и флэшмобы.
19. Проектировать приложения для социальных сетей.
20. Создавать и продвигать мероприятия.
21. Адаптировать кампанию под нишевые социальные сети.
22. Управлять кампанией вирусного посева.
23. Работать с геосервисами.
24. Нейтрализовывать негатив в социальных сетях и блогах.
25. Работать с системой оферов.
26. Проектировать и проводить спецпроекты.
27. Работать с социальными сетями профессиональных связей.
28. Понимать принципы формирования рейтингов и топов.
29. Создавать брендированные каналы на видеохостингах.
30. Выстраивать партнерские программы в социальных сетях.
31. Пользоваться сервисами для оптимизации SMM-работ.

Коммьюнити-менеджмент

32. Направлять обсуждения в нужное русло.
33. Нейтрализовывать негативных пользователей в сообществах.
34. Повышать активность пользователей в сообществах.
35. Повышать возвраты в сообщества.
36. Организовывать и проводить онлайн-эвенты.
37. Настраивать службу поддержки через социальные сети.

Контент-менеджмент

38. Создавать карту контента для различных площадок.
39. Адаптировать существующий контент (статьи, новости, посты) под различные форматы (блог, Twitter, Facebook, ВКонтакте).
40. Писать тексты в формате каждой из социальных сетей.
41. Писать тексты в блоговом формате.
42. Писать в формате Википедии.
43. Писать в формате Twitter.
44. Писать и распространять социальные релизы.
45. Готовить инфоповоды.
46. Создавать сценарии для видео.

Работа с интерфейсами

47. Брендировать сообщества.
48. Создавать дизайн сообществ.
49. Интегрировать сайт с социальными сетями.
50. Интегрировать интернет-магазин в социальные сети.
51. Внедрять в сообщество стимулы для вступления.
52. Создавать Landing Pages.
53. Создавать Welcome Page.
54. Вручную создавать вкладки.
55. Использовать сервисы для создания вкладок на Facebook.
56. Понимать механизмы повышения конверсии сайта.
57. Работать с Wordpress, RSS, Feedburner, ShareThis и с другими механизмами Stand-Alone блогов.

Работа с лидерами мнений

58. Выделять лидеров мнений целевой аудитории.
59. Организовывать эвенты для лидеров мнений.
60. Проводить акции сэмплинга.
61. Вести работу с сообществами «гражданских маркетологов».
62. Ангажировать администраторов тематических сообществ.
63. Работать с амбассадорами бренда.

Аналитика

64. Пользоваться системами автоматизированного мониторинга.
65. Мониторить социальные сети и блоги вручную.
66. Проводить аналитику инфоповодов.
67. Проводить аналитику тональности упоминаний.
68. Находить источники негатива в социальных сетях и блогах.
69. Анализировать эффективность кампании.
70. Работать с основными системами веб-аналитики.
71. Генерировать уникальные URL.
72. Отслеживать источники и качество трафика.
73. Выставлять целевые действия кампании.
74. Просчитывать стоимость целевого действия.
75. Проводить аналитику изменения информационного поля.
76. Проводить исследования в социальных сетях.
77. Определять природу негатива (естественный — направленный).
78. Пользоваться внутренними системами статистики социальных сетей.

Общемаркетинговые навыки

79. Общаться с редакциями онлайн-СМИ.
80. Понимать законы социальной психологии.
81. Проводить SWOT-анализ.
82. Формулировать УТП.
83. Заниматься медиапланингом.
84. Заниматься медиабайингом.
85. Инициировать републикации материалов.
86. Просчитывать себестоимость кампании.
87. Понимать специфику работы с персональными брендами.
88. Понимать новые digital-инструменты (mobile, дополненная реальность).
89. Пользоваться классическими интернет-маркетинговыми инструментами (контекстная реклама, медийная реклама, SEO).

Общие менеджерские навыки

90. Брифовать клиента.
91. Вести переговоры.
92. Отслеживать тренды в SMM.
93. Находить подрядчиков и управлять процессом работы с ними.
94. Формулировать кейсы на основе успешных кампаний.
95. Готовить презентации.
96. Готовить календарный план кампании и придерживаться его.
97. Готовить отчеты.
98. Защищать перед клиентом концепции, отчеты, новые предложения.
99. Организовывать брэйншторминг в проектной группе.
100. Управлять проектами.

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

Сети для самых маленьких. Часть девятая. Мультикаст / Хабр


Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

Традиционный видеоурок:

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

В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP-snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.

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

Уже гораздо позже я пришёл в к следующему правилу:

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


Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Как известно, существуют следующие типы трафика:
Unicast — одноадресная рассылка — один отправитель, один получатель. (Пример: запрос HTTP-странички у WEB-сервера).
Broadcast — широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (Пример: ARP-запрос).
Multicast — многоадресная рассылка — один отправитель, много получателей. (Пример: IPTV).
Anycast — одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (Пример: Anycast DNS).

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

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

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

Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.

Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.

Сформулируем два основных принципа мультикастовой рассылки:

  1. Отправитель посылает только одну копию трафика, независимо от количества получателей.
  2. Трафик получают только те, кто действительно заинтересован в нём.



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

Пример I


Начнём с самого простого случая:

На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.

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

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

Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?».
Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.

Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.

В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.

Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример II


Добавим в схему коммутатор и ещё несколько клиентов:

Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

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

Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.
Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов
Адрес Значение
224.0.0.0 Не используется
224.0.0.1 Все узлы данного сегмента
224.0.0.2 Все мультикастовые узлы данного сегмента
224.0.0.4 Данный адрес выделялся для покойного протокола DVMRP
224.0.0.5 Все OSPF-маршрутизаторы сегмента
224.0.0.6 Все DR маршрутизаторы сегмента
224.0.0.9 Все RIPv2-маршрутизаторы сегмента
224.0.0.10 Все EIGRP-маршрутизаторы сегмента
224.0.0.13 Все PIM-маршрутизаторы сегмента
224.0.0.18 Все VRRP-маршрутизаторы сегмента
224.0.0.19-21 Все IS-IS-маршрутизаторы сегмента
224.0.0.22 Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102 Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107 PTPv2 — Precision Time Protocol
224.0.0.251 mDNS
224.0.0.252 LLMNR
224.0.0.253 Teredo
224.0.1.1 NTP
224.0.1.39 Cisco Auto-RP-Announce
224.0.1.40 Cisco Auto-RP-Discovery
224.0.1.41 H.323 Gatekeeper
224.0.1.129-132 PTPv1/PTPv2
239.255.255.250 SSDP


Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

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

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

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.



Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?

Это сообщение протокола IGMP, которое отправил клиент, когда мы на нём нажали Play. Именно так он сообщает о том, что хочет получать трафик для группы 224.2.2.4.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.

В IPv6 используется MLD (Multicast Listener Discovery) вместо IGMP. Принцип работы у них абсолютно одинаковый, поэтому далее везде вы смело можете менять IGMP на MLD, а IP на IPv6.

Как же именно работает IGMP?
Пожалуй, начать нужно с того, что версий у протокола сейчас три: IGMPv1, IGMPv2, IGMPv3. Наиболее используемая — вторая, первая уже практически забыта, поэтому про неё говорить не будем, третья очень похожа на вторую.

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

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

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

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


1. Как только мы запустили приложение на клиенте и задали группу 224.2.2.4, в сеть будет отправлен пакет IGMP Membership Report — узел «рапортует» о том, что хочет получать трафик этой группы.

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

Часто в литературе вы можете встретить упоминание о IGMP Join. Не пугайтесь — это альтернативное название для IGMP Membership Report.


2. Маршрутизатор получает IGMP-Report и, понимая, что за данным интерфейсом теперь есть клиенты, заносит информацию в свои таблицы

Это вывод информации по IGMP. Первая группа запрошена клиентом. Третья и четвёртая — это служебные группы протокола SSDP, встроенного в Windows. Вторая — специальная группа, которая всегда присутствует на маршрутизаторах Cisco — она используется для протокола Auto-RP, который по умолчанию активирован на маршрутизаторах.
Интерфейс FE0/0 становится нисходящим для трафика группы 224.2.2.4 — в него нужно будет отправлять полученный трафик.

Наряду с обычной юникастовой таблицей маршрутизации существует ещё и мультикастовая:

О наличии клиентов говорит первая запись (*, 224.2.2.4). А запись (172.16.0.5, 224.2.2.4) означает, что маршрутизатор знает об источнике мультикастового потока для этой группы.
Из вывода видно, что трафик для группы 224.2.2.4 приходит через FE0/1, а передавать его надо на порт FE0/0.
Интерфейсы, в которые нужно передавать трафик, входят в список нисходящих интерфейсов — OIL — Outbound Interface List.
Более подробно вывод команды show ip mroute мы разберём позже.

Выше на дампе вы видите, что как только клиент отправил IGMP-Report, сразу после него полетели UDP — это видеопоток.


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

*Дамп отфильтрован по IGMP*.

По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?».

Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы.

*Дамп отфильтрован по IGMP*.

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

По своей инициативе клиент обычно посылает Report только при подключении, потом — просто отвечает на Query от маршрутизатора.

Интересная деталь в поведении клиента: получив Query, он не торопится сразу же ответить Report’ом. Узел берёт тайм-аут длиной от 0 до Max Response Time, который указан в пришедшем Query:

При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд.
Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report.
Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо.
Этот механизм называется Report Suppression.

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



4. Так продолжается веками, пока клиент не захочет выйти из группы (например, выключит плеер/телевизор). В этом случае он отправляет IGMP Leave на адрес группы.

Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех.
Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать?

Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query. На него отвечают только те клиенты, которые подключены к данной конкретной группе.

Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера.

Всего после получения Leave отправляется два Group Specific Query — один обязательный, второй контрольный.

*Дамп отфильтрован по IGMP*.

Далее маршрутизатор останавливает поток.


Querier


Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.
Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
1) Активировали IGMP на интерфейсах.
2) Сначала по умолчанию каждый из них считает себя Querier.
3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Выборы Querier очень важная процедура в мультикасте, но некоторые коварные производители, не придерживающиеся RFC, могут вставить крепкую палку в колёса. Я сейчас говорю о IGMP Query с адресом источника 0.0.0.0, которые могут генерироваться коммутатором. Такие сообщения не должны участвовать в выборе Querier, но надо быть готовыми ко всему. Вот пример весьма сложной долгоиграющей проблемы.


Ещё пара слов о других версиях IGMP


Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.
Кроме того, не поддерживаются выборы Querier. За избежание дублирования трафика отвечает вышестоящий протокол, например, PIM, о котором мы будем говорить далее.

Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22. А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим дальше.

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast. В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.

Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру II, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.


Повторим ещё раз

*Дамп отфильтрован по IGMP*.

1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.
3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4).
5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
6. Потом он передумал и отказался от группы, отправив IGMP Leave.
7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.


И ещё раз


IGMP — протокол, с помощью которого маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении.
IGMP Report — посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.
IGMP General Query — посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.
IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
IGMP Leave — посылается клиентом, когда тот хочет покинуть группу.
Querier — если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

Подробное описание всех терминов IGMP.



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

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

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP, MOSPF, CBT — все они по-разному решают такую задачу. Но стандартом де факто стал PIM — Protocol Independent Multicast.
Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:
CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

PIM имеет две версии, которые можно даже назвать двумя различными протоколами в принципе, уж сильно они разные:

  • PIM Dense Mode (DM)
  • PIM Sparse Mode (SM)

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

PIM Dense Mode


PIM DM пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.
Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде.
После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree.

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP, где корнем является источник.

SPT — это конкретный вид дерева — дерево кратчайшего пути. А вообще любое мультикастовое дерево называется MDT — Multicast Distribution Tree.

Предполагается, что PIM DM должен использоваться в сетях с высокой плотностью мультикастовых клиентов, что и объясняет его название (Dense). Но реальность такова, что эта ситуация — скорее, исключение, и зачастую PIM DM нецелесообразен.

Что нам действительно важно сейчас — это механизм избежания петель.
Представим такую сеть:

Один источник, один получатель и простейшая IP-сеть между ними. На всех маршрутизаторах запущен PIM DM.

Что произошло бы, если бы не было специального механизма избежания петель?
Источник отправляет мультикастовый трафик. R1 его получает и в соответствии с принципами PIM DM отправляет во все интерфейсы, кроме того, откуда он пришёл — то есть на R2 и R3.

R2 поступает точно так же, то есть отправляет трафик в сторону R3. R3 не может определить, что это тот же самый трафик, который он уже получил от R1, поэтому пересылает его во все свои интерфейсы. R1 получит копию трафика от R3 и так далее. Вот она — петля.

Что же предлагает PIM в такой ситуации? RPF — Reverse Path Forwarding. Это главный принцип передачи мультикастового трафика в PIM (любого вида: и DM и SM) — трафик от источника должен приходить по кратчайшему пути.
То есть для каждого полученного мультикастового пакета производится проверка на основе таблицы маршрутизации, оттуда ли он пришёл.

1) Маршрутизатор смотрит на адрес источника мультикастового пакета.
2) Проверяет таблицу маршрутизации, через какой интерфейс доступен адрес источника.
3) Проверяет интерфейс, через который пришёл мультикастовый пакет.
4) Если интерфейсы совпадают — всё отлично, мультикастовый пакет пропускается, если же данные приходят с другого интерфейса — они будут отброшены.
В нашем примере R3 знает, что кратчайший путь до источника лежит через R1 (статический или динамический маршрут). Поэтому мультикастовые пакеты, пришедшие от R1, проходят проверку и принимаются R3, а те, что пришли от R2, отбрасываются.

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

Останавливаться здесь и подробно рассматривать работу PIM DM мы не будем — это устаревший протокол с массой недостатков (ну, как RIP).

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





PIM Sparse Mode


Совершенно другой подход применяет PIM SM. Несмотря на название (разреженный режим), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM.
Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений PIM Join.
Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет.

Для того, чтобы понять, как работает PIM, начнём с уже знакомой нам простой сети с одним PIM-маршрутизатором:

Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах (в сторону источника и в сторону клиента) и IGMP в сторону клиента. Помимо прочих базовых настроек, конечно (IP, IGP).

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

	R1(config)#ip multicast-routing
	R1(config)#int fa0/0
	R1(config-if)#ip pim sparse-mode
	R1(config-if)#int fa1/0
	R1(config-if)#ip pim sparse-mode

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

Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1, например). Об этом позже, пока примите как данность и смиритесь.


Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4:

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

Давайте разберём этот немногословный вывод.

Запись вида (*, 225.0.1.1) называется (*, G), /читается старкомаджи/ и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик.
Если список нисходящих интерфейсов (OIL) пуст — Null, значит нет получателей — а мы их пока не запускали.

Запись (172.16.0.5, 225.0.1.1) называется (S, G), /читается эскомаджи/ и говорит о том, что известен источник. В нашем случае источник с адресом 172.16.0.5 вещает трафик для группы 224.2.2.4. Мультикастовый трафик приходит на интерфейс FE0/1 — это восходящий (Upstream) интерфейс.

Итак, нет клиентов. Трафик от источника доходит до маршрутизатора и на этом его жизнь кончается. Давайте добавим теперь получателя — настроим приём мультикаста на ПК.
ПК отсылает IGMP Report, маршрутизатор понимает, что появились клиенты и обновляет таблицу мультикастовой маршрутизации.
Теперь она выглядит так:

Появился и нисходящий интерфейс: FE0/0, что вполне ожидаемо. Причём он появился как в (*, G), так и в (S, G). Список нисходящих интерфейсов называется OIL — Outgoing Interface List.

Добавим ещё одного клиента на интерфейс FE1/0:

Если читать вывод дословно, то имеем:
(*, G): Есть получатели мультикастового трафика для группы 224.2.2.4 за интерфейсами FE0/0, FE1/0. Причём совершенно неважно, кто отправитель, о чём и говорит знак «*».

(S, G): Когда мультикастовый трафик с адресом назначения 224.2.2.4 от источника 172.16.0.5 приходит на интерфейс FE0/1, его копии нужно отправить в FE0/0 и FE1/0.

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


Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной


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

Но пока не запущен PIM, IGMP, клиенты не запрашивают каналы.

Файл начальной конфигурации.

Итак, момент времени 0.

Включаем мультикастовую маршрутизацию на всех пяти маршрутизаторах:

	RX(config)#ip multicast-routing

PIM включается непосредственно на всех интерфейсах всех маршрутизаторов (в том числе на интерфейсе в сторону Сервера-источника и клиентов):
	RX(config)#int FEX/X
	RX(config-if)#ip pim sparse-mode

IGMP, по идее должен включаться на интерфейсах в сторону клиентов, но, как мы уже отметили выше, на оборудовании Cisco он включается автоматически вместе с PIM.



Первое, что делает PIM — устанавливает соседство. Для этого используются сообщения PIM Hello. При активации PIM на интерфейсе с него отправляется PIM Hello на адрес 224.0.0.13 с TTL равным 1. Это означает, что соседями могут быть только маршрутизаторы, находящиеся в одном широковещательном домене.

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

Теперь они готовы принимать заявки на мультикастовые группы.

Если мы сейчас запустим в вольер клиентов с одной стороны и включим мультикастовый поток с сервера с другой, то R1 получит поток трафика, а R4 получит IGMP Report при попытке клиента подключиться. В итоге R1 не будет знать ничего о получателях, а R4 об источнике.

Неплохо было бы если бы информация об источнике и о клиентах группы была собрана где-то в одном месте. Но в каком?

Такая точка встречи называется Rendezvous Point — RP. Это центральное понятие PIM SM. Без неё ничего бы не работало. Здесь встречаются источник и получатели.
Все PIM-маршрутизаторы должны знать, кто является RP в домене, то есть знать её IP-адрес.

Чтобы построить дерево MDT, в сети выбирается в качестве RP некая центральная точка, которая,

  1. отвечает за изучение источника,
  2. является точкой притяжения сообщений Join от всех заинтересованных.

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

Пусть пока R2 будет выполнять роль RP.
Чтобы увеличить надёжность, обычно выбирается адрес Loopback-интерфейса. Поэтому на всех маршрутизаторах выполняется команда:

	RX(config)#ip pim rp-address 2.2.2.2

Естественно, этот адрес должен быть доступен по таблице маршрутизации со всех точек.
Ну и поскольку адрес 2.2.2.2 является RP, на интерфейсе Loopback 0 на R2 желательно тоже активировать PIM.
	R2(config)#interface Loopback 0
	RX(config-if)#ip pim sparse-mode

Сразу после этого R4 узнает об источнике трафика для группы 224.2.2.4:

и даже передаёт трафик:

На интерфейс FE0/1 приходит 362000 б/с, и через интерфейс FE0/0 они передаются.

Всё, что мы сделали:
Включили возможность маршрутизации мультикастового трафика (ip multicast-routing)
Активировали PIM на интерфейсах (ip pim sparse-mode)
Указали адрес RP (ip pim rp-adress X.X.X.X)

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


Разбор полётов


Ну так и как же в итоге всё работает? Как RP узнаёт где источник, где клиенты и обеспечивает связь между ними?

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

1) Клиент 1 отправляет IGMP Report для группы 224.2.2.4

2) R4 получает этот запрос, понимает, что есть клиент за интерфейсом FE0/0, добавляет этот интерфейс в OIL и формирует запись (*, G).

Здесь видно восходящий интерфейс FE0/1, но это не значит, что R4 получает трафик для группы 224.2.2.4. Это говорит лишь о том, что единственное место, откуда сейчас он может получать — FE0/1, потому что именно там находится RP. Кстати, здесь же указан и сосед, который прошёл RPF-Check — R2: 10.0.2.24. Ожидаемо.

R4 называется — LHR (Last Hop Router) — последний маршрутизатор на пути мультикастового трафика, если считать от источника. Иными словами — это маршрутизатор, ближайший к получателю. Для Клиента1 — это R4, для Клиента2 — это R5.

3) Поскольку на R4 пока нет мультикастового потока (он его не запрашивал прежде), он формирует сообщение PIM Join и отправляет его в сторону RP (2.2.2.2).

PIM Join отправляется мультикастом на адрес 224.0.0.13. «В сторону RP» означает через интерфейс, который указан в таблице маршрутизации, как outbound для того адреса, который указан внутри пакета. В нашем случае это 2.2.2.2 — адрес RP. Такой Join обозначается ещё как Join (*,G) и говорит: «Не важно, кто источник, мне нужен трафик группы 224.2.2.4».
То есть каждый маршрутизатор на пути должен обработать такой Join и при необходимости отправить новый Join в сторону RP. (Важно понимать, что если на маршрутизаторе уже есть эта группа, он не будет отправлять выше Join — он просто добавит интерфейс, с которого пришёл Join, в OIL и начнёт передавать трафик).
В нашем случае Join ушёл в FE0/1:

4) R2, получив Join, формирует запись (*, G) и добавляет интерфейс FE0/0 в OIL. Но Join отсылать уже некуда — он сам уже RP, а про источник пока ничего не известно.

Таким образом RP узнаёт о том, где находятся клиенты.

Если Клиент 2 тоже захочет получать мультикастовый трафик для той же группы, R5 отправит PIM Join в FE0/1, потому что за ним находится RP, R3, получив его, формирует новый PIM Join и отправляет в FE1/1 — туда, где находится RP.
То есть Join путешествует так узел за узлом, пока не доберётся до RP или до другого маршрутизатора, где уже есть клиенты этой группы.

Итак, R2 — наш RP — сейчас знает о том, что за FE0/0 и FE1/0 у него есть получатели для группы 224.2.2.4.
Причём неважно, сколько их там — по одному за каждым интерфейсом или по сто — поток трафика всё равно будет один на интерфейс.

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

Отдалённо напоминает дерево, не так ли? Поэтому оно так и называется — RPT — Rendezvous Point Tree. Это дерево с корнем в RP, а ветви которого простираются до клиентов.
Более общий термин, как мы упоминали выше, — MDT — Multicast Distribution Tree — дерево, вдоль которого распространяется мультикастовый поток. Позже вы увидите разницу между MDT и RPT.

5) Теперь врубаем сервер. Как мы уже выше обсуждали, он не волнуется о PIM, RP, IGMP — он просто вещает. А R1 получает этот поток. Его задача — доставить мультикаст до RP.
В PIM есть специальный тип сообщений — Register. Он нужен для того, чтобы зарегистрировать источник мультикаста на RP.
Итак, R1 получает мультикастовый поток группы 224.2.2.4:

R1 является FHR (First Hop Router) — первый маршрутизатор на пути мультикастового трафика или ближайший к источнику.

6) Далее он инкапсулирует каждый полученный от источника мультикастовый пакет в юникастовый PIM Register и отправляет его прямиком на RP.

Обратите внимание на стек протоколов. Поверх юникастового IP и заголовка PIM идёт изначальный мультикастовый IP, UDP и данные.
Теперь, в отличие от всех других, пока известных нам сообщений PIM, в адресе получателя указан 2.2.2.2, а не мультикастовый адрес.

Такой пакет доставляется до RP по стандартным правилам юникастовой маршрутизации и несёт в себе изначальный мультикастовый пакет, то есть это… это же туннелирование!

=====================
Задача № 1

Схема и начальная конфигурация.

На сервере 172.16.0.5 работает приложение, которое может передавать пакеты только на широковещательный адрес 255.255.255.255, с портом получателя UDP 10999.

Этот трафик надо доставить к клиентам 1 и 2:
Клиенту 1 в виде мультикаст трафика с адресом группы 239.9.9.9.
А в сегмент клиента 2, в виде широковещательных пакетов на адрес 255.255.255.255.

Подробности задачи тут.
=====================

7) RP получает PIM Register, распаковывает его и обнаруживает под обёрткой трафик для группы 224.2.2.4.
Информацию об этом он сразу заносит в свою таблицу мультикастовой маршрутизации:

Появилась запись (S, G) — (172.16.0.5, 224.2.2.4).
Распакованные пакеты RP дальше отправляет в RPT в интерфейсы FE0/0 и FE1/0, по которому трафик доходит до клиентов.

В принципе, на этом можно было бы и остановиться. Всё работает — клиенты получают трафик. Но есть две проблемы:

  1. Процессы инкапсуляции и декапсуляции — весьма затратные действия для маршрутизаторов. Кроме того, дополнительные заголовки увеличивают размер пакета, и он может просто не пролезть в MTU где-то на промежуточном узле (вспоминаем все проблемы туннелирования).
  2. Если вдруг где-то между источником и RP есть ещё получатели для группы, мультикастовому трафику придётся пройти один путь дважды.

Возьмём для примера вот такую топологию:

Трафик в сообщениях Register сначала дойдёт до RP по линии R1-R42-R2, затем чистый мультикаст вернётся по линии R2-R42. Таким образом на линии R42-R2 будет ходить две копии одного трафика, пусть и в противоположных направлениях.

Поэтому лучше от источника до RP тоже передавать чистый мультикаст, а для этого нужно построить дерево — Source Tree.

8) Поэтому RP отправляет на R1 сообщение PIM Join. Но теперь уже в

MiRS — Интегрированная микроволновая поисковая система — Описание приборов

Javascript в настоящее время отключен на этот компьютер. Без javascript многие улучшения отображения не работают; однако весь контент должен быть полностью видимым и доступным.

фото: прибор SSMIS

Спутник (а)

F16, F17, F18

Состояние производства MiRS

F16: Ранее действовал.
F17 и F18: В настоящее время работает.

СВЧ-тепловизор / эхолот со специальным датчиком (SSMIS) продолжает наследие пассивных микроволновых приборов на борту Defense Спутники метеорологической спутниковой программы (DMSP). Начиная с запуск спутника DMSP F-16 18 октября 2003 г., SSMIS отмечает начало производства новой серии пассивных микроволновых устройств с коническим сканированием тепловизоры и эхолоты, запуск которых запланирован на следующие два десятилетия (Sun и Вэн 2008). SSMIS улучшает восстановление поверхности и атмосферы специальный сенсорный микроволновый тепловизор (SSM / I), а также атмосферный возможности зондирования температуры и водяного пара как специальных Датчик микроволнового датчика температуры (SSM / T-1) и специальный датчик СВЧ-датчик влажности (SSM / T-2).Кроме того, изображения SSMIS и датчики зондирования имеют одинаковую геометрию обзора, что позволяет параметры, которые должны быть получены одновременно (Ян и Вэн, 2008 г.). SSMIS прибор может определять температуру, влажность и параметры поверхности из данных, собранных на частотах от 19 до 183 ГГц при ширине полосы обзора 1707 км.


Характеристики датчика SSMIS F16
Канал Center Freq.(ГГц) Полоса пропускания (МГц) Freq. (МГц) / поляризация NEDT (макс.) (Тыс.) Интервал отбора проб (км) Площадь основания (км)
1 50,3 400 10 В 0,4 37,5 38 х 38
2 52,8 400 10 В 0.4 37,5 38 х 38
3 53,596 400 10 В 0,4 37,5 38 х 38
4 54,4 400 10 В 0,4 37,5 38 х 38
5 55,5 400 10 В 0.4 37,5 38 х 38
6 57.29 350 10 RCP (*) 0,5 37,5 38 х 38
7 59,4 250 10 RCP 0,6 37,5 38 х 38
8 150 1500 200 H 0.88 37,5 14 x 13 (тепловизор)
9 183,31 ± 6,6 1500 200 H 1,2 37,5 14 x 13 (тепловизор)
10 183,31 ± 3 1000 200 H 1,0 37,5 14 x 13 (тепловизор)
11 183.31 ± 1 500 200 H 1,25 37,5 14 x 13 (тепловизор)
12 19,35 400 75 H 0,7 25 73 х 47
13 19,35 400 75 В 0,7 25 73 х 47
14 22.235 400 75 В 0,7 25 73 х 47
15 37 1500 75 H 0,5 25 41 х 31
16 37 1500 75 В 0,5 25 41 х 31
17 91.655 3000 100 В 0,9 12,5 14 x 13 (тепловизор)
18 91.655 3000 100 ч 0,9 12,5 14 x 13 (тепловизор)
19 63,283248 ± 0,285271 3 0,08 RCP 2,4 75 75 х 75
20 60.792668 ± 0,357892 3 0,08 RCP 2,4 75 75 х 75
21 60,792668 ± 0,357892 ± 0,002 6 0,08 RCP 1,8 75 75 х 75
22 60,792668 ± 0,357892 ± 0,006 12 0,12 RCP 1,0 75 75 х 75
23 60.792668 ± 0,357892 ± 0,016 32 0,34 RCP 0,6 75 75 х 75
24 60,792668 ± 0,357892 ± 0,050 120 0,84 RCP 0,7 37,5 75 х 75
Характеристики датчика SSMIS F18
(отличается от F16: первые 5 каналов горизонтальны)
Канал Center Freq.(ГГц) Полоса пропускания (МГц) Freq. (МГц) / поляризация NEDT (макс.) (Тыс.) Интервал отбора проб (км) Площадь основания (км)
1 50,3 400 10 H 0,4 37,5 38 x 38
2 52,8 400 10 H 0,4 37.5 38 x 38
3 53,596 400 10 H 0,4 37,5 38 x 38
4 54,4 400 10 H 0,4 37,5 38 x 38
5 55,5 400 10 H 0,4 37.5 38 x 38
6 57,29 350 10 RCP (*) 0,5 37,5 38 x 38
7 59,4 250 10 RCP 0,6 37,5 38 x 38
8 150 1500 200 H 0,88 37.5 14 x 13 (имидж-сканер)
9 183,31 ± 6,6 1500 200 H 1,2 37,5 14 x 13 (имидж-сканер)
10 183,31 ± 3 1000 200 H 1,0 37,5 14 x 13 (имидж-сканер)
11 183,31 ± 1 500 200 H 1.25 37,5 14 x 13 (имидж-сканер)
12 19,35 400 75 H 0,7 25 73 x 47
13 19,35 400 75 В 0,7 25 73 x 47
14 22,235 400 75 В 0.7 25 73 x 47
15 37 1500 75 H 0,5 25 41 x 31
16 37 1500 75 V 0,5 25 41 x 31
17 91,655 3000 100 V 0.9 12,5 14 x 13 (имидж-сканер)
18 91,655 3000100 H 0,9 12,5 14 x 13 (имидж-сканер)
19 63,283248 ± 0,285271 3 0,08 RCP 2,4 75 75 x 75
20 60,792668 ± 0,357892 3 0.08 RCP 2,4 75 75 x 75
21 60,792668 ± 0,357892 ± 0,002 6 0,08 RCP 1,8 75 75 x 75
22 60,792668 ± 0,357892 ± 0,006 12 0,12 RCP 1,0 75 75 x 75
23 60,792668 ± 0,357892 ± 0.016 32 0,34 RCP 0,6 75 75 x 75
24 60,792668 ± 0,357892 ± 0,050120 0,84 RCP 0,7 37,5 75 x 75

RCP — обозначает правую круговую поляризацию.


Источник: NSIDC SSMIS, страница

Примеры поляризации


Вертикальная поляризация
Горизонтальная поляризация
Левая круговая поляризация (LHCP),
также известен как CCW (против часовой стрелки)
Правая круговая поляризация (RHCP),
также известен как CW (по часовой стрелке)

SSMIS — SSMIS — qaz.вики

Czujnika specjalne mikrofalowa Imager / akustyczny (SSMIS) jest 24 kanałów 21 częstotliwości, spolaryzowane liniowo pasywny mikrofalowa Radiometr systemu. Przyrz programd pływa na pokładzie United States Air Force Defense Meteorological programu satelitarnego (DMSP) F-16, F-17, F-18 i F-19 satelitów, który rozpoczął działalność w listopadzie 2005 roku, marzec odpied i March 2016. Jest następcą Specjalny czujnik / Microwave Imager (SSM / I). SSMIS na satelicie F17 zaprzestał produkcji użytecznych danych w kwietniu 2016 r.

Charakterystyka instrumentów

Геометрия скан SSM / I (SSMIS mają skanować kąt 143,2 Grad)

Czujnik SSMIS jest pasywnym stożkowo skanowania mikrofalowa radiometru, który łczy i rozciąga bieżącego obrazu i brzmiące możliwości poprzednio trzech oddzielnych czujchrofilów Dzujników. SSMIS zmierzonej wartości energii mikrofalowej na 24 oddzielnych częstotliwości od 19 до 183 GHz или szerokości roboczej 1700 км.Pierwszy SSMIS został uruchomiony na pokładzie satelity DMSP-16 w dniu 18 października 2003. Z powodu błędu produkcyjnego, polaryzacji dla kanałów przy 50,3, 52,8, 53,6, 54,4 SS i 55,5 pierwsdenzejata na DMSP- 16) został odwrócony. Te pięć kanałów wykrywania polaryzacji pionowej raczej niż polaryzacja pozioma wykryty przez kolejnych jednostek SSMIS.

Tabela 1: radiometryczne cechy SSMIS [1].

Częstotliwość

(ГГц)

Polaryzacja
wzdłuż toru

Rozdzielczość (км)

Поперечный путь

Rozdzielczość (км)

Przestrzenny

Próbkowanie (kmxkm)

Инструмент

Szumów (K)

19,35 позиции 73 47 45×74 0,35
19,35 pionowy 73 47 45×74 0,35
22 235 pionowy 73 47 45×74 0,45
37,0 позиции 41 31 28×45 0.22
37,0 pionowy 41 31 28×45 0,22
50,3 позиции 17,6 27,3 37,5 0,34
52,8 позиции 17,6 27,3 37,5 0,32
53 596 позиции 17,6 27,3 37,5 0.33
54,4 позиции 17,6 27,3 37,5 0,33
55,5 позиции 17,6 27,3 37,5 0,34
57,29 prawo okrągły 17,6 27,3 37,5 0,41
59,4 prawo okrągły 17,6 27,3 37,5 0.40
63,283248 ± 0,285271 prawo okrągły 17,6 27,3 75 2,7
60,792668 ± 0,357892 prawo okrągły 17,6 27,3 75 2,7
60,792668 ± ± 0,002 0,357892 prawo okrągły 17,6 27,3 75 1,9
60.792668 ± 0,0055 ± 0,357892 prawo okrągły 17,6 27,3 75 1,3
60,792668 ± 0,016 ± 0,357892 prawo okrągły 17,6 27,3 75 0,8
60,792668 ± 0,050 ± 0,357892 prawo okrągły 17,6 27,3 75 0,9
91 665 позиции 14 13 13×16 0.19
91 665 pionowy 14 13 13×16 0,19
150 позиции 14 13 13×16 0,53
183 311 ± 1 позиции 14 13 13×16 0,38
183 311 ± 3 позиции 14 13 13×16 0.39
183 311 ± 6,6 позиции 14 13 13×16 0,56

Referencje

Что такое AWS Systems Manager?

AWS Systems Manager — это сервис AWS, который можно использовать для просмотра инфраструктуры и управления ею. на AWS.Используя консоль System Manager, вы можете просматривать рабочие данные с нескольких Сервисы AWS и автоматизировать операционные задачи в рамках ресурсов AWS. Systems Manager поможет вам поддерживать безопасность и соответствие путем сканирования ваших управляемых экземпляров и сообщать (или предпринимать корректирующие действия) любые обнаруженные нарушения политики.

Управляемый экземпляр — это компьютер, настроенный для использования с Systems Manager. Системный менеджер также помогает настраивать и поддерживать управляемые экземпляры. Поддерживаемые типы машин включают EC2 экземпляры, локальные серверы и виртуальные машины (ВМ), включая ВМ в других облако среды.Поддерживаемые типы операционных систем включают Windows Server, macOS, Raspbian и несколько дистрибутивов Linux ,.

Используя Systems Manager, вы можете связать ресурсы AWS вместе, применяя одинаковые идентификация ресурсных тегов каждому из них. Затем вы можете просмотреть оперативные данные для этих ресурсов как группа ресурсов , чтобы помочь контролировать и устранять неполадки.

Например, вы можете назначить тег ресурса « Operation = North Region OS. Обновление «для всех следующих ресурсов:

  • Группа инстансов EC2

  • Группа локальных серверов на собственном предприятии

  • Базовый уровень исправлений Systems Manager, который указывает, какие исправления следует применять к управляемой экземпляры

  • Корзина S3 для хранения выходных данных журнала операций исправления

  • Окно обслуживания System Manager , в котором указывается график исправления

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

Возможности в System Manager

Systems Manager состоит из отдельных возможностей , которые сгруппированы в пять категорий: Управление операциями , Управление приложениями , Действия и Измените , Экземпляры и узлы и Общие ресурсы .

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

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

  • Централизованное определение параметров конфигурации и политик для вашего управляемого экземпляры.

  • Централизованно просматривайте, исследуйте и решайте рабочие задачи, связанные с AWS Ресурсы.

  • Автоматизируйте или планируйте различные задачи обслуживания и развертывания.

  • Использование и создание документов SSM в стиле Runbook , которые определите действия, которые нужно выполнить с вашими управляемыми экземплярами.

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

  • Безопасное подключение к управляемому экземпляру одним щелчком мыши без необходимости открывать входящий порт или управлять ключами SSH.

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

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

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

  • Быстро узнайте, какие ресурсы в вашем аккаунте не соответствуют требованиям, и примите корректирующие действия с централизованной приборной панели.

  • Просматривайте активные сводки показателей и аварийных сигналов для ресурсов AWS.

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

Видео: что такое AWS Systems Manager?

Просмотрите ознакомительный видеоролик о Systems Manager (Продолжительность: 1:42)

Посмотреть больше видеороликов AWS на веб-сервисах Amazon YouTube Канал.

Поддерживается Systems Manager Регионы AWS

AWS Systems Manager доступен в регионах AWS, перечисленных в конечных точках сервисов Systems Manager в Общий справочник по веб-службам Amazon .Перед тем, как начать процесс настройки Systems Manager, мы рекомендуем вам обеспечить сервис доступен в каждом из регионов AWS, в котором вы хотите его использовать.

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

Цены на Системный менеджер

Некоторые возможности System Manager требуют оплаты.Для получения дополнительной информации см. AWS Systems Manager. Ценообразование.

Системный менеджер история имен службы

AWS Systems Manager (Системный менеджер) ранее назывался Amazon Simple Systems Manager (SSM) »и« Системный менеджер Amazon EC2 (SSM) ».В оригинальное сокращенное название сервиса «SSM» — все еще отражено в различных ресурсах AWS, включая несколько других сервисных консолей. Несколько примеров:

  • Агент системного менеджера : Агент SSM

  • Параметры администратора системы : SSM параметры

  • Конечные точки службы Systems Manager : ССМ.us-east-2.amazonaws.com

  • Типы ресурсов AWS CloudFormation : AWS :: SSM :: Документ

  • Идентификатор правила AWS Config : EC2_INSTANCE_MANAGED_BY_SSM

  • Команды интерфейса командной строки AWS : aws ssm описать патч базовые линии

  • Управляемая политика AWS Identity and Access Management (IAM) имена : AmazonSSMReadOnlyAccess

  • Системный менеджер ресурсов ARN : arn: aws: ssm: us-east-2: 111222333444: patchbaseline / pb-07d8884178 ПРИМЕР

Связанное содержание

  • Следующие ресурсы помогут вам работать напрямую с Systems Manager.

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

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

    • Инструменты разработчика AWS — Ссылки на инструменты разработчика, SDK, наборы инструментов IDE и инструменты командной строки. для разработки и управления приложениями AWS.

    • Официальные документы AWS — Ссылки на полный список технических документов AWS, охватывающих такие темы, как архитектура, безопасность и экономика, разработанные AWS Архитекторы решений или другие технические эксперты.

    • Центр поддержки AWS — Центр для создания и управления вашим Обращения в службу поддержки AWS.Также включает ссылки на другие полезные ресурсы, такие как форумы, технические часто задаваемые вопросы, состояние работоспособности сервиса и AWS Trusted Advisor.

    • AWS Support — Основная веб-страница для информации об AWS Support: индивидуальная поддержка с быстрым откликом канал, который поможет вам создавать и запускать приложения в облаке.

    • Свяжитесь с нами — Центральный контактный пункт для запросов, касающихся Платежи AWS, аккаунт, события, злоупотребления и другие проблемы.

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

Подробнее о Systems Manager

Работа с агентом SSM — AWS Systems Manager

AWS Systems Manager Agent (агент SSM) — это программное обеспечение Amazon, которое можно установить и настроен на Экземпляр EC2, локальный сервер или виртуальная машина (ВМ).Агент SSM делает это возможно для Systems Manager для обновления, управления и настройки этих ресурсов. Агент обрабатывает Запросы из сервиса Systems Manager в облаке AWS, а затем запускает их, как указано в запросе. Затем агент SSM отправляет информацию о состоянии и выполнении обратно в System Manager. сервис с помощью Amazon Message Delivery Service (префикс услуги: сообщения ec2 ).

Если вы отслеживаете трафик, вы увидите свое Amazon Elastic Compute Cloud (Amazon EC2) экземпляры и любые локальные серверы или виртуальные машины в гибридной среде, связь с сообщениями ec2. * конечными точками. Для получения дополнительной информации см. Ссылка: ec2messages, ssmmessages и другие вызовы API. Для информации о портировании Агент SSM ведет журналы в Amazon CloudWatch Logs, см. Мониторинг AWS Systems Manager.

Постоянное обновление агента SSM

Обновленная версия SSM Agent выпускается всякий раз, когда в Системный менеджер или обновляются существующие возможности. Если работает более старая версия агента на Например, некоторые процессы агента SSM могут дать сбой.По этой причине мы рекомендуем вам автоматизировать процесс поддержания агента SSM в актуальном состоянии на ваших экземплярах. Для получения информации см. Автоматическое обновление агента SSM. Чтобы получать уведомления об обновлениях агента SSM, подпишитесь на агента SSM. Страница примечаний к выпуску на GitHub.

образов машин Amazon (AMI), которые по умолчанию включают агент SSM, может занять до двух недель. быть обновленным до последней версии SSM Agent.Рекомендуем настроить четный более частые автоматические обновления агента SSM.

Обновленные версии агента SSM развертываются в новых регионах AWS в разное время. По этой причине вы можете получить сообщение «Не поддерживается на текущей платформе» или «Обновление amazon-ssm-agent на старую версию, пожалуйста, разрешите переход на более раннюю версию » ошибка при попытке развернуть новую версию агента SSM в регионе.

Агент SSM и служба метаданных экземпляра (IMDS)

Systems Manager для правильной работы полагается на метаданные экземпляра EC2. Системный менеджер может получить доступ к экземпляру метаданные с использованием версии 1 или версии 2 метаданных экземпляра Сервис (IMDSv1 и IMDSv2).Для большего информацию см. в разделе Метаданные экземпляра и данные пользователя в Amazon EC2 User Guide for Linux Instances .

Приоритет учетных данных агента SSM

Когда агент SSM установлен на экземпляре, ему требуются разрешения для общаться со службой Systems Manager.В инстансах EC2 эти разрешения предоставляются в профиль экземпляра, прикрепленный к экземпляру. В гибридном экземпляре SSM Агент обычно получает необходимые разрешения из файла общих учетных данных, расположенного в /root/.aws/credentials (Linux) или % ​​ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ% \.aws \ credentials (Windows). Необходимые разрешения добавляются к этому файлу в процессе гибридной активации.

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

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

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

В Linux агент SSM работает от имени пользователя root. Следовательно, окружающая среда файл переменных и учетных данных, которые агент SSM ищет в этом процессе, — это те из только пользователь root ( / root /.aws / credentials ). Агент SSM не смотрит на переменные среды или файл учетных данных любых других учетных записей пользователей на пример во время поиска учетных данных.

Цепочка поставщиков по умолчанию ищет учетные данные в следующем порядке:

  1. Переменные среды, если настроены ( AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY ).

  2. Файл общих учетных данных ( $ HOME / .aws / credentials для Linux или % ​​USERPROFILE% \. Aws \ credentials для Windows) с разрешениями, предоставляемыми, например, гибридным активация или установка AWS CLI.

  3. Роль AWS Identity and Access Management (IAM) для задач при наличии приложения который использует Определение задачи Amazon Elastic Container Service (Amazon ECS) или RunTask API операция.

  4. Профиль инстанса, прикрепленный к инстансу Amazon EC2.

Для получения дополнительной информации см. Следующие разделы:

О локальной учетной записи ssm-пользователя

Начиная с версии 2.3.50.0 агента SSM, агент создает локальную учетную запись пользователя. называется ssm-user и добавляет его в / etc / sudoers (Linux и macOS) или в группу администраторов (Windows). В версиях агента до 2.3.612.0, учетная запись создается при первом запуске или перезапуске агента SSM после установки. На версия 2.3.612.0 и новее, учетная запись ssm-user создается в первый раз сеанс запускается на экземпляре. Этот ssm-user является пользователем ОС по умолчанию при запуске сеанса диспетчера сеансов. Вы можете изменить разрешения, переместив ssm-user в менее привилегированную группу или изменив sudoers файл.Аккаунт ssm-user не удаляется из системы при удалении агента SSM.

В Windows Server агент SSM обрабатывает установку нового пароля для учетной записи ssm-user когда начинается каждый сеанс. Для ssm-пользователя в Linux пароли не установлены экземпляры.

Начиная с версии 2.3.612.0 агента SSM, учетная запись ssm-user не создается автоматически на компьютерах Windows Server, которые используются в качестве контроллеров домена. Чтобы использовать диспетчер сеансов на контроллере домена Windows Server необходимо вручную создать учетную запись ssm-user если его еще нет.

AMI с предустановленным агентом SSM

Агент SSM

предварительно установлен по умолчанию в следующих образах компьютеров Amazon (AMI):

  • Amazon Linux

  • Amazon Linux 2

  • Amazon Linux 2 AMI, оптимизированные для ECS

  • macOS 10.14.x (Мохаве) и 10.15.x (Каталина)

  • Ubuntu Server 16.04, 18.04 и 20.04

  • Windows Server 2008-2012 R2 AMI, опубликованные в ноябре 2016 г. или позже

  • Windows Server 2016 и 2019

Агент SSM

устанавливается не на все AMI на базе Amazon Linux или Amazon Linux 2.Например, агент SSM не предустановлен на AMI, оптимизированных для EKS, на базе Amazon. Linux 2.

Необходимо вручную установить агент SSM на EC2 экземпляры, созданные из других AMI Linux. Вы также должны вручную установить агент SSM на локальные серверы или виртуальные машины в гибридной среде.Для получения дополнительной информации см. Настройка AWS Systems Manager для гибридной среды.

Агент SSM

может быть предварительно установлен на AMI сообщества, которые поддерживают другие операционные системы. AWS не поддерживает эти AMI сообщества.

Агент SSM на GitHub

Исходный код SSM Agent доступен на GitHub, так что вы можете адаптировать агент для удовлетворения ваших потребностей. Мы рекомендуем вам отправить pull запросы на изменения, которые вы хотели бы включить.Тем не мение, Amazon Web Services в настоящее время не поддерживает запуск модифицированные копии этого программного обеспечения.

SSMI и SSMIS netCDF Data Products

Продукты данных SSMI и SSMIS netCDF

Содержание

Введение

Эти наборы данных являются частью коллекции Special Сенсорный СВЧ / тепловизор (SSM / I) и СВЧ-тепловизор со специальным датчиком Данные Sounder (SSMIS), выпущенные в рамках программы НАСА MEaSUREs.Системы дистанционного зондирования генерируют SSM / I и продукты двоичных данных SSMIS с использованием унифицированного, физически основанного алгоритма для одновременного определения скорости ветра в океане (на 10 метров), водяного пара, облачная вода и интенсивность дождя. Данные SSMIS были тщательно интеркалиброван по уровню яркостной температуры с предыдущим SSM / I и, следовательно, расширяют этот важный временной ряд океанских ветров, значения пара, облаков и дождя. Этот алгоритм является результатом 20-летнего опыта уточнения, улучшения и проверки.Центр глобальных гидрологических ресурсов (GHRC), научный центр данных НАСА, управляемый Алабамским университетом в Хантсвилле, переформатировал двоичные данные версии 7 в продукт данных netCDF для каждого временная группа для каждого спутника. Версия 7 netCDF SSMI / SSMIS коллекция будет доступна для F8, F10, F11, F13, F14, F15, F16 и F17 для каждой временной агрегации: ежедневно, 3 дня, еженедельно и ежемесячно.

Описание прибора

Наборы данных GHRC SSM / I и SSMIS netCDF состоят из данных полученные из наблюдений, собранных с помощью приборов SSM / I и SSMIS, проводимых на борту полярно-орбитальных спутников серии DMSP.Эти спутники номер:

Спутниковая

Дата начала

Дата окончания

F08 SSM / I

июл 1987

декабрь 1991

F10 SSM / I

декабрь 1990

ноя 1997

F11 SSM / I

декабрь 1991

Май 2000

F13 SSM / I

мая 1995

ноя 2009

F14 SSM / I

мая 1997

августа 2008 г.

* F15 SSM / I

декабрь 1999

декабрь 2011 г. (двоичные данные V6 с 2012 г. и далее доступны через RSS)

F16 SSM / I

октябрь 2003

присутствует

F17 SSMIS

декабрь 2006

присутствует

* Примечание: НЕ ИСПОЛЬЗУЙТЕ данные F15 из 14 августа 2006 г. вперед для исследования климата.С 14 августа 2006 г., UTC, 22 ГГц (V) на SSM / I F15 был ухудшен радиомаяком RADCAL. Более подробную информацию можно можно найти на http://www.ssmi.com/ssmi/ssmi_F15_RADCAL_beacon_correction.html.

Следователь

Фрэнк Венц
Системы дистанционного зондирования
444 Десятая улица, Suite 200
Santa Rosa, CA 95401

Соглашение об именах файлов

Ежедневные файлы состоят из одного файла в день.

fnn_S_yyyymmddv7.nc

файлов в среднем за 3 дня состоят из одного файла с датой. день окончания 3-дневного периода.

fnn_S_yyyymmddv7_d3d.nc

Файлы со средним значением за неделю состоят из одного файла с дата - день окончания недельного периода.

fnn_S_yyyymmddv7_wk.nc

Среднемесячные файлы состоят из одного файла с дата является месяцем (обратите внимание, что день отсутствует).

fnn_S_yyyymmv7.nc

где

nn - номер спутника (08-17)
S - имя спутника (ssmi, ssmis)
yyyy - год из 4 цифр
мм - месяц из 2 цифр
dd - день недели из 2 цифр месяц
nc - формат netCDF

Формат данных

SSM / I и SSMIS RSS двоичные данные версии 7 были переформатированы в netCDF Формат версии 4 (основан на HDF версии 5).Все данные в формат сетки. Есть ежедневные файлы с 2 сетками: по возрастанию и один для нисходящих перевалов. Есть три файла с сетками на 3 дня, средние за неделю и за месяц. Все файлы содержат сетки для 10-метровой поверхности. скорость ветра, столбчатый водяной пар, столбчатое облако, жидкая вода и дождь показатель. В файле netCDF есть размеры; гео, время и данные переменные; и атрибуты.

Размеры названы и всегда состоят из следующий набор:

"Широта" - количество горизонтальных линий в данных. сетки (всегда 720)
«Долгота» - это количество вертикальных линий в сетки данных (всегда 1440)
«Время» - количество проходов (ежедневные файлы только, всегда 2, если есть)

Переменные с фиксированными названиями «Широта» и «Долгота». определены во всех файлах данных SSM / I netCDF.Переменная "SST_DTime" определяется только в ежедневных файлах.

«Широта» и «Долгота» хранятся как одномерные массивы 32-битных значений с плавающей запятой с размерами под названием "широта" и «долгота». Допустимые значения широты от -89,875 до +89,875. (От южного полюса до северного полюса «центры пикселей») и допустимые значения долготы. диапазон от +0,125 (к востоку от линии дат) к востоку до 359,875 (к западу линии дат).

Определены следующие поля данных:

" SST_DTime " сохраняется как двумерный массив (с размерами "широта" на "долгота") 16-битные целые числа со знаком.Значение шкалы 0,1 должно применяться к значения для получения значения времени, представляющего количество часов с момента начало дня, GMT, которое представляет дневной файл. Действительный диапазон составляет от 0,0 до 24,0 м / с.

" 10-метровая скорость приземного ветра ": A двумерный массив ("широта" на "долгота") 16-битных подписанных целые числа. Значение шкалы 0,2 должно применяться для получения реального значения. Допустимый диапазон реальных значений - 0.От 0 до 50,0.

" Колонна водяного пара ": двумерный массив ("широта" на "долгота") 16-битных целых чисел со знаком. Значение шкалы 0,3 применяется для получения реальных значений. Допустимый диапазон реальные значения от 0,0 до 75,0 кг / м2.

" Жидкая вода в виде столбиков из облаков ": A двумерный массив ("широта" на "долгота") 16-битных подписанных целые числа. Значение шкалы 0,01, затем необходимо применить смещение -0,05. производить реальные ценности.Допустимый диапазон реальных значений от -0,05 до 2,45 кг / м2.

" Rain Rate ": двумерный массив. («широта» на «долгота») 16-разрядных целых чисел со знаком, содержащих данные. Значение шкалы 0,1 должно применяться для получения реальных значений. В допустимый диапазон реальных значений от 0,0 до 25,0 мм / час.

Значения данных, масштабирование и смещения из двоичного файла RSS. файлы были сохранены при переводе в netCDF, так что прямая копия значения, хранящиеся в двоичных файлах RSS для 4 полей данных, могут быть сделано без изменения каких-либо значений.

netCDF 4 поддерживает сжатие данных, но требует, чтобы данные должны быть разбиты на «куски». Все двумерные массивы разбиваются на блоки с использованием Размер блока 2x90x90 для ежедневных файлов или 90x90 для 3-дневных, еженедельных и среднемесячные файлы и сжатые. Чанкинг и сжатие в netCDF невидимы для конечного пользователя, поскольку поля не разбиты на части и не сжаты по мере необходимости по мере их чтения. Были проведены тесты для определения разумного размер блока, проводя эксперименты с размерами квадратных блоков с размерами которые делятся равномерно на 720 (размер «широты»).Кусок слишком маленькие размеры ухудшают степень сжатия и делают данные медленнее читать, а слишком большие размеры блоков могут привести к подмножеству неэффективно. Выбор 90 x 90 был в "золотой зоне", когда нужно было больше оказывает незначительное влияние на сжатие и размер дает 128 "плиток" данных (8x16), чтобы, возможно, помочь с подмножеством.

Глобальные атрибуты

netCDF содержат метаданные о файле. Следующие атрибуты (все символьные строки) определены в SSM / I и файлы данных SSMIS:

«Заголовок»: имя набора данных.
«Учреждение»: Учреждения, участвующие в создании файлов данных.
«Источник»: Источник данных в файлах.
"История": Историческая справка, включая происхождение (предоставление документации о том, где и когда файлы были созданы).
«Ссылки»: URL-адрес документации, содержащей описание данных.
«Комментарий»: Примечания к данным, содержащие более подробное описание истории, источника и данных содержимое файла.
"Масштаб": сводка значений шкалы, которые должны быть применяется к каждой переменной в файле для получения реального значения.
"Значение": сводка используемых специальных значений, которые должны быть интерпретируется особым образом. Для SSM / I и SSMIS такими значениями являются вне допустимого диапазона и являются значениями флагов.
"SatID": спутник ID в виде "DMSP-Fnn", где nn - спутник количество.
«SensorID»: идентификатор сенсора, который является «SSM / I» или «ССМИС».
"identifier_product_DOI": идентификатор цифрового объекта (DOI) для файла данных.
"PassDirection": сводка используемых значений. для направления прохода (1 для восходящего, 2 для по убыванию).
«NumberOfPasses»: количество проходов, сохраненных в файл данных (2 для ежедневных файлов, 1 для других).
"ChunkSize": размер используемой квадратной плитки. Было выбрано 90, в результате размер блока 2x90x90 для ежедневных файлов с 2 проходами и 90x90 для других файлы.
«Конвенции»: конвенция CF (климат и прогноз). номер версии для соглашений CF, используемых для файла данных.

Алгоритм и этапы обработки

Эти специальные микроволновые печи / тепловизоры (SSM / I) и специальные Информационные продукты Sensor Microwave Imager Sounder (SSMIS) производятся как часть программы НАСА MEaSUREs. Системы дистанционного зондирования генерируют SSM / I и Продукты данных SSMIS, использующие унифицированный физический алгоритм для одновременно получить скорость ветра в океане (на 10 метров), атмосферную воду пар, жидкая вода из облаков и интенсивность дождя.Этот алгоритм является продуктом 20 лет доработок, улучшений и проверок. В то время как алгоритмы эволюционировали с течением времени, что является существенным основанием для радиационная передаточная функция, используемая для получения геофизических параметров: описаны в следующих статьях:

Преобразование формата netCDF и Проверка

Подмножество файлов данных в формате netCDF было сравнено и проверено RSS в отношении исходного содержания данных в двоичном формате формат.RSS предоставил GHRC образцы выходных данных из двоичной версии для каждый из наборов данных. GHRC проверил значения netCDF по образцу вывод с использованием внутренней программы проверки, Panoply и интегрированного Data Viewer (IDV) и обнаружил, что содержимое данных netCDF совпадает с двоичный формат. RSS также проверил содержание.

Читать программное обеспечение

netCDF

Библиотека netCDF используется для чтения или записи файлов netCDF. Он доступен для нескольких языков, включая Java, C ++, C, FORTRAN, и другие.На момент написания этой статьи библиотека netCDF-Java находится по адресу версия 4.2 и библиотеки C / C ++ также находятся в версии 4.2. Версия 4.2 или более поздней версии рекомендуется, поскольку более ранние версии могут не полностью поддерживать параметры сжатия и фрагментирования, используемые в файлах SSM / I и SSMIS. В Библиотеки netCDF и netCDF-Java можно бесплатно скачать с NCSA по адресу http://www.unidata.ucar.edu/downloads/netcdf/. Доступны файлы Java JAR, в которых есть зависимости, что делает настройка проекта намного проще.Для других языков другие библиотеки должны быть получен в двоичной форме и установлен или скомпилирован из исходного кода.

HDF 5

Поскольку netCDF основан на HDF 5, библиотека HDF версии 5 требуется для. На момент написания этой статьи HDF5-1.8.9 является последней версия. Рекомендуется эта версия или более поздняя. HDF можно скачать бесплатно платы от NCSA на http://www.hdfgroup.org/HDF5/release/obtain5.html. Обратите внимание, что NSCA предоставляет предварительно скомпилированные двоичные файлы для многих платформ или исходных кодов. код, если вы хотите решить проблему настройки библиотеки для ваша система.

SZIP

HDF 5 требует библиотеки SZIP для сжатия. SZIP можно бесплатно загрузить с сайта NCSA по адресу http://www.hdfgroup.org/HDF5/release/obtain5.html. NCSA предоставляет предварительно скомпилированные двоичные файлы или исходный код для этого пакета.

ZLIB

HDF 5 требует библиотеки ZLIB для выполнения сжатия. ZLIB можно бесплатно загрузить с сайта NCSA по адресу http: // www.hdfgroup.org/HDF5/release/obtain5.html. NCSA предоставляет предварительно скомпилированные двоичные файлы или исходный код для этого пакета.

JPEG

HDF 5 требует библиотеки JPEG для выполнения сжатия. JPEG можно бесплатно загрузить с сайта NCSA по адресу http://www.hdfgroup.org/HDF5/release/obtain5.html. NCSA предоставляет предварительно скомпилированные двоичные файлы или исходный код для этого пакета.

Дополнительная информация о необходимом программном обеспечении и о том, как ссылку и скомпилировать программу можно в SSM / I и данные SSMIS в Руководстве пользователя NetCDF.Также есть образец чтения программа доступна по адресу ftp://ghrc.nsstc.nasa.gov/pub/doc/ssmi_netcdf/ReadNetCDF.c.

Инструменты

Существует ряд бесплатных пакетов, которые можно загружен для проверки и работы с файлами netCDF. Многие из них могут быть можно найти на веб-сайте HDF-EOS http://hdfeos.org/software.

Panoply - это кроссплатформенное приложение Java, которое отображает массивы с географической сеткой из наборов данных netCDF. Есть версии, специфичные для Mac OS X и Windows, а также общие версии для других платформ, которые поддержка Java 6.Panoply доступен по адресу http://www.giss.nasa.gov/tools/panoply/. .

The Integrated Data Viewer (IDV) - это программное обеспечение на основе Java. структура для анализа и визуализации геолого-геофизических данных. IDV - это разработан в Центре программ Unidata (UPC), входящем в состав Университета Корпорация атмосферных исследований (UCAR), Боулдер, Колорадо, финансируется Национальным научным фондом. Программное обеспечение свободно доступна в соответствии с условиями Стандартной общественной лицензии ограниченного применения GNU и является доступно по адресу http: // www.unidata.ucar.edu/software/idv/.

ПЛАН, http://miningsolutions.itsc.uah.edu/glider/content/glider-features, является бесплатный инструмент для простой визуализации, анализа и анализа спутниковых изображений. GLIDER позволяет пользователям визуализировать и анализировать спутниковые данные в исходном виде. сенсорный вид. Пользователи могут улучшить изображение, применив другое изображение алгоритмы обработки данных. GLIDER предоставляет пользователям полную набор алгоритмов распознавания образов и интеллектуального анализа данных, которые могут быть применяется к спутниковым снимкам для извлечения тематической информации.В набор алгоритмов включает как контролируемые, так и неконтролируемые алгоритмы классификации. Кроме того, пользователи могут проецировать спутниковые изображения и результаты анализа / добычи на трехмерном глобусе для визуализации. GLIDER также позволяет пользователям добавлять дополнительные слои к глобусу вместе с проецируемое изображение. Пользователи могут открывать несколько представлений в GLIDER, чтобы одновременно управлять, визуализировать и анализировать множество файлов данных.

Цитата

Наши наборы данных предоставляются через Проект NASA Earth Science Data and Information System (ESDIS) и Центр распределенных активных архивов Глобального центра гидрологических ресурсов (GHRC) (DAAC).GHRC DAAC является одним из данных системы наблюдения за Землей НАСА и Информационная система (EOSDIS) центры обработки данных, которые являются частью ESDIS проект. Данные ESDIS не защищены авторским правом; однако, если вы публиковать наши данные или результаты, полученные с использованием наших данных, мы просим вас включить подтверждение в текст статьи и ссылку на ваш список ссылок. Примеры общих благодарностей, набор данных цитирование в списке ссылок, а также упоминание изображений в Интернете и информацию можно найти по адресу: http: // ghrc.nsstc.nasa.gov/uso/citation.html

Список литературы

Венц Ф. Дж. 1997, "Хорошо откалиброванный алгоритм океана для SSM / I", J. Geophys. Res., Vol. 102, № C4, стр. 8703-8718.

Венц Франк Дж. 2013, «Отчет о калибровке SSM / I версии 7», Системы дистанционного зондирования, Санта-Роза, Калифорния.

Венц, Франк Дж. И Рой В. Спенсеры, 1 мая 1998 г., "Извлечение дождя SSM / I в Единый всепогодный алгоритм океана ", Журнал атмосферных наук, Vol.55, стр. 1613-1627.

Венц, Франк Дж. И Томас Мейснер, 2000, "Алгоритм океана AMSR, версия 2", номер отчета 121599A-1, Системы дистанционного зондирования, Санта-Роза, Калифорния, 66 стр.

Венц, Франк Дж. И Томас Мейснер, 2007, "Приложение 1 Теоретические основы алгоритмов Базовый документ для алгоритмов океана AMSR-E ", Системы дистанционного зондирования, Санта Роза, Калифорния.

Описание Системы дистанционного зондирования, версия 7, геофизические извлечения, автор: Hilburn et al. al., 2010.

Контактная информация

Чтобы заказать эти данные или дополнительную информацию, пожалуйста, контакт:

Глобальный центр ресурсов по гидрологии
Службы пользователей
320 Sparkman Drive
Huntsville, AL 35805
Телефон: 256-961-7932
Эл. Почта: [email protected]
Интернет: http://ghrc.nsstc.nasa.gov/

ssm command man page - system-storage-manager

Synopsis

ssm [ -h ] [ --version ] [ -v ] [ -v ** v] [ -v ** vv] [ -f ] [ -b BACKEND] [ -n ] {проверка, изменение размера, создание, список, информация, добавление, удаление, моментальный снимок, монтирование, перенос}...

ssm create [ -h ] [ -s SIZE] [ -n NAME] [ --fstype FSTYPE] [ -r LEVEL] [ -I STRIPESIZE] [ -i STRIPES] [ -p POOL] [ -e [{luks, plain}]] [ -o MNT_OPTIONS] [ -v VIRTUAL_SIZE] [ устройство ... ] [mount]

ssm list [ -h ] [{тома, объем, dev, устройства, пул, пулы, файловые системы, моментальные снимки, снимки}]

ssm info [ -h ] [item]

ssm remove [ -h ] [ -a ] [ items ...]

ssm resize [ -h ] [ -s SIZE] volume [ device ...]

ssm check [ 915 -h ] устройство [ устройство ...]

снимок ssm [ -h ] [ -s SIZE] [ -d DEST | -n NAME] volume

ssm add [ -h ] [ -p POOL] device [ device ...]

ssm mount [ -h ] [ -o Options] volume directory

ssm migrate [ -h ] source

09 target0 Описание

System Storage Manager предоставляет простой в использовании интерфейс командной строки для управления хранилищем с использованием различных технологий, таких как lvm, btrfs, зашифрованные тома и другие.

В более сложных корпоративных средах хранения данных управление с помощью Device Mapper (dm), Logical Volume Manager (LVM) или Multiple Devices (md) становится все более трудным.С добавлением файловых систем количество инструментов, необходимых для настройки хранилища и управления им, стало настолько большим, что оно просто неудобно для пользователя. При таком большом количестве вариантов, которые должен учитывать системный администратор, вероятность ошибок и проблем велика.

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

Команды System Storage Manager

Введение

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

Создать команду

ssm create [ -h ] [ -s SIZE] [ -n NAME] [ --fstype FSTYPE] [ -r LEVEL] [ -I 915 STRIPESIZE] [ -i STRIPES] [ -p POOL] [ -e [{luks, plain}]] [ -o MNT_OPTIONS] [ -v VIRTUAL_SIZE] [ устройство ...] [mount]

Эта команда создает новый том с определенными параметрами. Если предоставляется устройство , оно будет использоваться для создания тома, следовательно, оно будет добавлено в пул до создания тома (см. Раздел «Добавить команду»). Для создания тома можно использовать более одного устройства.

Если устройство уже используется в другом пуле, тогда ssm спросит вас, хотите ли вы удалить его из исходного пула. Если вы отказываетесь или удаление не удается, создание тома не удастся, если РАЗМЕР не был предоставлен.С другой стороны, если предоставляется РАЗМЕР и некоторые устройства не могут быть добавлены в пул , создание тома все равно может быть успешным, если в пуле достаточно места.

Помимо непосредственного указания размера тома, можно также указать процент. Укажите --size 70% , чтобы указать, что размер тома составляет 70% от общего размера пула. Кроме того, процент используемого или свободного пространства в пуле также можно указать с помощью ключевых слов FREE или USED соответственно.

Также можно указать имя POOL . Если пул существует, новый том будет создан из этого пула (необязательно добавление devi

.