Я обещал больше технических видео про новинки софта на своем канале по возвращению – я делаю 😉 И отдельное спасибо Microsoft за новые оригинальные “фичи”, которые появляются в Windows 10, и, в частности, в WSL (Windows Subsystem for Linux). Про сам WSL 2 и его возможности по “родному” запуску приложений Linux прямо из Windows 10 я уже рассказывал здесь – https://youtu.be/cUM4UVum_Ck – и здесь – https://youtu.be/P88GPegg7x0 – но предыдущие сборки Windows Subsystem for Linux v2 работали по умолчанию только с консольными версиями Linux приложений и чтобы запустить графические GUI приложения от Linux – требовалось существенно пошаманить, иногда – без гарантии ожидаемого результата работы графики. Для шаманства, чтобы заставить работать WSL2 с графикой, использовались различные X-серверы для Windows типа Xming, но заботало оно кривовато.
И вот – в новой сборке Windows 10 Insider Preview 21364 появилась новая версия ядра WSL, которое теперь работает с графическими приложениями из коробки и не требует специальных плясок с бубнами – WSLg. Т.е. теперь практически любое GUI приложение Linux будет работать “в графике” в WSL2 сразу из коробки и рядом с “окошками Windows 10” c их традиционным оформлением вы будете видеть и окна в стиле X запущенных линуксовских приложение. Кстати, работает это все очень просто в ядре системы – специальный драйвер в WSLg выдает RDP Windows за X-сервер для запускаемых графических Linux приложений. Т.е. фактически – каждое окно Linux-приложения – это всего лишь сессия RDP к ядру самого хоста, в которую отправляет картинку WSLg. Решение простое и эффективное для базовых GUI приложений, Microsoft эффективно использует его уже много лет для публикации не всего рабочего стола, а отдельных приложений на RDS серверах и теперь еще и на Azure WVD, но есть одно НО… И это НО – производительность работы RDP сессии при активно меняющейся картинке, например, видео или игр. В принципе – оно тепримо, но особо видео не посмотришь и в игры с высокими FPS на таком Linux не поиграешь. Хотя Quake я таки запустил для демонстрации.
И о демонстрации в данном видео и “на попробовать самому” – как я уже говорил, особых действий после установки новой сборки Windows 10 Insider Preview 21364 (или новее) не требуется. Если WSL2 уже установлен – требуется обновить его ядро, если WSL2 еще не установлен – установить само ядро Linux WSL2 в Windows 10 и установить какую-то из сборок Linux с поддержкой WSL2. Как это делается – описано в документации – https://github.com/microsoft/wslg#welcome-to-wslg – буквально одна команда – или wsl –update , или wsl –install -d Ubintu (или другой дистрибутив из списка на выбор wls –list –online). Кстати, где-то в траблешутинге встречал упоминания о том, что пока нормально работают с графикой сборки только Ubuntu 18/20 (и просто Ubuntu – это ссылка на последнюю стабильную версию) – так что установить Ubuntu для теста WSLg рекомендуется. А дальше – следуем рекомендациям в той же доке https://github.com/microsoft/wslg#install-and-run-gui-apps – и устанавливаем различные тестовые GUI приложения Linux, типа gedit, chrome, edge и прочих. Кстати, я поступил по другому – я просто из примера сделал шеловский скриптик и запустил его. Кроме того, чтобы было более интересно – я также установил Quake (.pak файлы взял скопировал в WSL через nautilus из оригинального Quake, который есть у меня в Steam), различные офисные пакеты типа WPS и LibreOffice, Kodi для Linux и, конечно же, сам агент Steam.
Результаты тестов вы можете видеть в самом видео – все работает без каких-либо проблем, достаточно шустро, особенно, если учитывать, что для записи я подключался к ноуту, на котором у меня стоит Windows 10 Insider Preview, через RDP, а, как я уже говорил выше, WSLg само по себе тоже RDP сессия – так что о том, что бывает с графикой, когда запускаешь видео в RDP, которое уже в RDP – думаю, вы знаете не по наслышке. НО, не смотря на то, что в Steam у меня нет приложений для Linux – очень порадовал режим стриминга игр на Linux агента Steam в WSLg (причем, с того же компа, на котором я вел запись) – удивительно хорошо шла картинка и никаких неудобств в игре я не чувствовал. Конечно, практического применения такая работа Steam не имеет, но как демонстрация возможностей WSLg – очень даже.
Хочу также обратить внимание, что все запущенные Linux GUI-приложения отображаются не только как сессии RDP, но и появляются в виде значков в строке задач Windows 10:
Кроме того, все установленные в WPS сборки Linux приложения автоматически добавляются в виде иконок/ссылок в меню Старт Windows 10 – так что в реальности – не обязательно даже будет заглядывать в консоль WPS и запускать приложения оттуда – Windows 10 по клику на иконку сама запустит нужную сборку и сессию для приложения в ней. А в меню Старт установленные Linux-приложения выглядят примерно так:
и запросто находятся тем же поиском Windows 10 в панеле задач, чтобы меньше кликать и скролить:
А каковы перспективы практического применения WSLg – смотрите в видео, думаю, с таким подходом скоро и Android Apps “поедут” на Windows 10. Но, если серьезно, особых перспектив массового использования WSLg и графических приложений Linux в Windows 10 конечными пользователями не ожидается. Это, скорее, удобный инструмент для разработчиков и ИТ-специалистов, который теперь позволяет иметь на рабочем столе Windows 10 инструменты с любой платформы без всяких там виртуальных машин и делает Windows 10 вполне такой действительно универсальной платформой.
Предыдущие видео про Windows Subsystem for Linux:
“Microsoft выпустил Windows 10 с ядром Linux” или как работает WSL2 в новой Insider сборке – https://youtu.be/cUM4UVum_Ck
СофТы: тестирование производительности Linux в Windows Subsystem for Linux vs Hyper-V – https://youtu.be/P88GPegg7x0
Windows 10: установка и настройка хакерского Kali Linux в Windows 10, как приложения WSL – https://youtu.be/RKFSJRSnLBw
Продолжаю тему «цифровой трансформации» в отношении к современным облачным Managed Services, которую я, пользуясь личным практическим опытом, частично осветил в первой части данной статьи. Напомню, там речь шла о концептуальных и стратегических отличиях новых облачных Managed Services от традиционных «динозавров» Managed Services, вкратце:
Поставщики облачных Managed Services выступают «головой», а не «руками» заказчика и концентрируются не на том, «чтобы все виртуальные машины работали», а на консультационной помощи заказчику по миграции в облака и модернизации приложений в формат «нативных» решений. Фактически, поставщик современных облачных Managed Services для заказчика – это, как модно говорить сейчас, «Trusted Advisor» по всему, что касается облаков.
Облачные Managed Services отвечают за SLA бизнес-процессов, а не за непонятный для бизнеса заказчика SLA времени ответа на запрос. Задача современных Managed Services обеспечить желаемый SLA для критического сервиса/приложения заказчика, используя все доступные средства облака и способствовать модернизации приложений.
Поставщик современных облачных Managed Services работает с заказчиком по принципу «непрерывного проекта миграции и модернизации», обеспечивая постоянное внедрение новых служб, решений и модернизацию существующих без переключения на «сторонние проекты».
Поставщик современных облачных Managed Services работает в непрерывном контакте с заказчиком, имея в команде технического менеджера, который поддерживает регулярную коммуникацию с заказчиком, знает о всех его планах и проблемах, обеспечивает координацию с различными командами и вендорами заказчика и управляет ресурсами своей команды и текущими проектами.
И, наконец, «цена вопроса» за услуги Managed Services, которая формируется не путем подсчета «виртуальных машин по головам», а в проценте от общей суммы утилизации Azure клиентом.
А в этой части мы поговорим о технологических и процедурных отличиях современных облачных поставщиков Managed Services по сравнению c «динозаврами» «традиционных» Managed Services.
В предыдущем посте я уже писал, что облака вообще и Azure в частности «добавляют новый, не достижимый ранее, уровень гибкости для Managed Services благодаря своим сервисам уведомлений, мониторинга, автоматизации, автоматического поддержания здоровья и безопасности поверх таких возможностей облаков, как эластичность, масштабируемость и отказоустойчивость». И ключевое слово тут – «совершенно новый уровень мониторинга и автоматизации».
Такой мониторинг и автоматизация в первую очередь должны быть направлены на обеспечение требуемого SLA для критических бизнес-сервисов и приложений заказчика, о котором говорилось в предыдущей части. И, учитывая специфику и возможности мониторинга в Azure и сервиса Azure Log Analytics – основной отличительной чертой современного провайдера Azure Managed Services является проактивный мониторинг с предсказанием тенденций по тем или иным показателям критических приложений и/или поиском аномалий в текущих показателях. Звучит красиво и непонятно, а в реальности – Azure Alert, который базируется на нескольких командах в запросе KUSTO к нужным данным, которые хранятся в таблицах Azure Log Analytics – и мы получаем, например, тенденцию уменьшения свободного места на диске исходя из показателей мониторинга последних 15-30 минут, часов, дней – в зависимости от того, насколько высоки требования к SLA решения и как «чутко» нам нужно реагировать на возможное отсутствие дискового пространства для серверов приложений и сколько за это готов платить заказчик. Напомню, что каждый такой Alert с запросом и собственно, время работы вызванной после процедуры Azure Automation стоит денег, пускай это идут центы, но при активном использовании с минутными интервалами – может набегать ощутимая сумма.
Сценарии применения такой «предсказательной» автоматизации – бесконечно обширны благодаря инструментарию управления в Azure. Конкретный пример с предсказанием окончания места на диске за несколько дней до критического значения (обычно 5-10%) в реальных инфраструктурах – это и оправка уведомлений всем заинтересованным лицам + создание «тикета» в системе управления того бизнес-приложения, у компонентов которого место на диске подходит к концу, и запуск Azure Automation runbook, который в ближайшее окно обслуживания остановит, если возможно, проблемную виртуальную машину и увеличит размер диска на ней. Другой сценарий – это предсказание изменения нагрузок (кол-ва запросов) на том же Azure Application Gateway, чтобы предварительно увеличивать/уменьшать количество работающих экземпляров App Gateway в зависимости от недельных/сезонных и общих тенденций, что позволяет обеспечивать и высокую доступность решения, и экономить деньги клиента, подстраивая количество экземпляров под реальные потребности. И да, я в курсе про autoscaling для App Gateway, но как показывает опыт – всегда стоит держать +1 экземпляр в горячем режиме про запас – потому что автоматическое масштабирование не успевает реагировать на те же атаки или даже просто резкий скачек нагрузки при каких-то онлайн событиях. А вот такие онлайн события по расписанию очень легко предсказывать на недельном форекасте и реагировать за 15-30 минут до их начала расширением пула и экземпляров App Gateway, и App Services, и SQL Database DTU, и прочих компонент приложения.
Интересной особенностью Azure Monitor и Azure Log Analytics является Azure VM Insights – возможность «заглядывать» в то, что происходит на уровне ядра OS виртуальных машин и получать информацию не только о показателях производительности базовых компонентов, но и, например (еще один реальный сценарий), мониторить и предсказывать «всплески» высокого уровня задержек сетевых соединений (outbound connection latency) процессов приложения при запросах между виртуальными машинами, на которых находятся компоненты приложения, или к базам данных. Опять же, зная суточные/недельные/месячные тенденции и текущие показатели – очень легко предсказывать возможные «залипания» соединений и быстро реагировать на проблемы путем увеличения количества виртуальных машин требуемого типа в пуле приложения. И да, заметьте, тут для масштабирования используются не стандартные показатели типа CPU/RAM/Disk или даже число запросов, а именно тот показатель, который может серьезно влиять на доступность и производительность приложения, не смотря на отсутствие явных признаков высокой утилизации конкретной виртуальной машины и всего решения в целом.
И чтобы не быть голословным (все-таки техническая часть) – вот вам небольшой пример того самого запроса KUSTO к Azure Log Analytics с визуальным предсказанием нагрузки App GW, который отображает общую почасовую тенденцию изменения трафика на App GW в следующие 3 дня исходя из истории предыдущих 5 дней:
let min_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize min(TimeGenerated));
let max_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize max(TimeGenerated));
AzureDiagnostics
| where TimeGenerated > ago(5d) and ResourceType == “APPLICATIONGATEWAYS” and OperationName == “ApplicationGatewayAccess”
| make-series Requests_H = count() on TimeGenerated from min_t to max_t+3d step 1h
Визуальный результат будет выглядеть так, где синий график – текущие показатели количества запросов к сайту за прошедшие 5 дней, а красный график – предсказание тенденций изменения трафика на следующие 3 дня:
А дальше – выполняя такие запросы по расписанию (и помним о цене запроса) и оценивая тенденции или находя аномалии – запускаем в случае критических показателей требуемые скрипты Azure Automation или других продуктов, которые внедрены в процессы компании.
Проактивный мониторинг инфраструктуры – это отличное средство обеспечения требуемых SLA, но не стоит игнорировать и стандартные средства эффективной реакции на проблемы инфраструктуры и приложений в Azure, такие, как уведомления/предупреждения о проблемах (служба Azure Alerts, являющаяся частью Azure Monitor) и автоматической проверки здоровья (Health checks/auto-healing, опции различных служб), работающие в той же связке с Azure Automation для реакции на события путем запуска требуемых Azure Automation Runbook.
На рынке существует достаточно большое количество решений, обеспечивающих сбор и мониторинг данных по работающей инфраструктуре в Azure, но в большинстве своем – это универсальные системы, строящие «красивые отчеты» и «дашбоарды» для различных компонентов, в то время, как для современных облачных Managed Services важно гарантировать SLA клиентского сервиса в целом, что уже упоминалось в первой части статьи. Потому для доведения решения до требуемой кондиции – контроля за SLA и реакции на возможные проблемы – все равно требуется доводка таких универсальных систем «напильником». И, как показал опыт – подстраивать сторонние готовые универсальные мониторинга системы под задачи конкретного заказчика – весьма утомительно и, часто, очень проблематично ввиду особенностей архитектуры этих систем. Кстати, об архитектуре систем – практически эта архитектура требует в тенанте (даже не подписке) заказчика наличия учетных записей с такими правами, на которые служба безопасности заказчика категорически не согласна. Так что приходится все это решать средствами собственных скриптов, объединяя с упомянутыми выше очень даже функциональными сервисами Azure. Как работает такая связка – я постарался вкратце рассказать в ходе недавнего онлайн семинара по Azure Automation и Azure Monitor/Log Analytics – https://youtu.be/a6VGeDUNYt4
Таким образом, современные Azure Managed Services базируются на обширном репозитории шаблонов скриптов и запросов, которые можно быстро адаптировать под потребности конкретного заказчика и задача команды современных облачных Managed Services – активно расширять и оптимизировать данный репозитарий.
Интересным аспектом является модный ныне DevOps, о котором столько разговоров. И да, вы правильно сделали выводы – если я не начал с самого начала нахваливать DevOps – он действительно не играет существенной роли в предоставлении Managed Services (если, конечно, вы не предоставляете DevOps, как одну из услуг Managed Services). Тот же практический опыт показал полное отсутствие каких-либо преимуществ применения DevOps перед традиционными средствами развертывания и управления инфраструктурой в Azure – типа шаблонов ARM, Azure Automation, DSC – для предоставления тех же услуг развертывания инфраструктуры в рамках Azure Managed Services. Почему так? – Да потому, что большинство инфраструктур заказчика стабильны и меняются не так часто, потому репозитория ARM шаблонов вполне достаточно и для начального развертывания, и для дальнейшей модификации/восстановления при сбоях. Что же касается программной части – тех же Azure Apps Services, Azure Data Platform, Kubernetes и прочих – в задачу Azure Managed Services входит их мониторинг и поддержка, а начальное «запиливание» кода в большинстве случаев – это ответственность команд разработчиков (причем, чаще – во множественном числе), которые работают над своим продуктом и со стороны поставщика Azure Managed Services им требуется готовая инфраструктура самой службы DevOps, настроенные системы мониторинга и реакции на проблемы со стороны Azure. Очень часто – разработчики вообще не представляют, какие функции управления инфраструктурой того, что они «наворотили», имеются в Azure и именно «обвес» мониторинга и высокой доступности всего решения в целом – куда входят и Application Gateway/WAF с CDN, и App Services с базами данных и хранилищами, и средства управления масштабированием и здоровьем, и репликации, а не отдельный экземпляр App Services – и является зоной ответственности команды Azure Managed Services и требует постоянного взаимодействия с командой разработчиков и разработки спецификаций, которые позволяют упростить процесс работы такой инфраструктуры и которым должны следовать разработчики в архитектуре своего решения.
Так что DevOps – это скорее нет, чем да… Или вы «подхватываете» у заказчика, а вернее – его поставщиков – функции разработки и DevOps по совместительству. Но это уже совсем не та история, которая про Azure Managed Services.
А вот следующая часть «той истории» современного облачного поставщика Azure Managed Services начинается в последних предложениях про DevOps о спецификациях – это называется Operational Excellence (OE) – по-русски звучит коряво – «Операционное Совершенствование» – потому буду использовать в тексте аббревиатуру OE. Operational Excellence я бы назвал одной из основных составляющих успеха после того, как вы наработали у себя в облачных Managed Services необходимый минимум репозитория шаблонов скриптов и дальше развиваете свой бизнес. Какие первоочередные задачи стоят перед OE в данном случае? Во-первых – это работа над спецификациями типа LLD benchmark checklist, Developers benchmark checklist и т.п. Все эти спецификации должны определять списки требования к архитектурам, которые планируют для ваших заказчиков либо ваши коллеги из Professional Services, либо разработчики заказчика, либо непосредственно ваши сотрудники, работающие в Managed Services. Такие OE спецификации для планирования решения чаще всего содержат в себе требования к наличию различных компонентов мониторинга и управления в дизайне по умолчанию. Например, для Azure LLD OE benchmark checklist это проверка архитектуры на:
· Наличие Azure Monitor Alert, который уведомляет о глобальных проблемах всех служб Azure
· Наличие Alert для критических значений вместимости и производительности для всех компонентов
· Наличие требуемых служб мониторинга – Azure VM Insights, Application Insights, Azure Log Analytics, Azure Security Center для критических компонентов
· Наличие карты требуемых процессов обслуживания
· Наличие автоматизации рутинных процессов с использованием Azure Automation
· Наличие карты зависимостей критических приложений, для которых будет требоваться SLA
· Наличие плана восстановления после сбоев
· Наличие списка других объектов/процедур, которые являются критическими в инфраструктуре и т.п.
Следующая часть OE – это внутренние процессы, такие, как контроль за процедурными документами и их соответствию текущему статусу инфраструктуры, улучшение основных процессов поддержки SLA путем внедрения результатов анализа каждого сбоя – Root Cause Analysis (RCA), и, самое главное – это наличие процессов анализа обращений клиентов с целью обнаружения типовых обращений и создания на их основе новых автоматических процедур или решений, которые обеспечивают доступ к требуемой информации/операций посредством порталов или приложений самообслуживания.
И да, Operational Excellence – это моя «боль», поскольку даже при очень хорошо продуманных процедурах, особенно внутренних – надо еще научить коллектив соблюдать эти процедуры. И здесь, опять же – приходит на помощь и автоматизация бизнес-процессов, и, конечно же, правильные KPI. Но это уже тема следующей части про действительно современные и актуальные облачные Managed Services.
Зато есть еще одна, упомянутая выше, технологическая часть Azure Managed Services, которая существенно отличается от «традиционных» – поскольку мы работаем с облаками и, как уже говорилось в первой части, не блокируем полностью клиентский доступ к инфраструктуре – тут у нас открывается обширное поле деятельности для создание решений по самообслуживанию, особенно, если OE работает и вы быстро определяете базовые рутинные потребности в обслуживании для каждого клиента Azure Managed Services. Что дальше? Безусловно – автоматизация или применение современного удобного инструментария/платформ разработки решений, которые позволяют максимально ускорить взаимодействие заказчика с его же инфраструктурой.
К чему это я? Все очень просто – такими инструментами и платформой для создания решений самообслуживания являются и сам Azure с его Log Analytics, Logic Apps, Automation, Functions, Cognitive Services, и платформа Power Platform c Power Apps, Power Virtual Agents. Применение Power Apps позволяет очень легко и просто предоставить заказчику, особенно менеджменту, простое приложение-панель информации для мобильных платформ (телефонов и планшетов) – наиболее востребованная, как показывает опыт и анализ запросов, функциональность – «хотим видеть на телефоне прямо в реальном времени состояние всех приложений и их компонентов (светофорчики)». Используя Power Apps и средства типа Log Analytics и Functions, которые вызываются из Power Apps – создание такого приложения занимает считанные дни, модификация – часы, а публикация – минуты. При этом такое простое приложение имеет громадный позитивный эффект на лояльность и удовлетворенность менеджмента заказчика предоставляемыми Azure Managed Services.
Второй сценарий – это автоматизация стандартных технических запросов от инженеров заказчика, которые обслуживают непосредственно приложения, обычно – внутри виртуальных машин и лезть куда-то в незнакомый портал и отвечать за «поломанное» им совершенно не интересно. Опять же, как показала практика – самый эффективный способ быстрой реакции на запрос – это автоматизация обработки почтовых сообщений, в которых с простым синтаксисом описываются требуемые операции, такие, как создание виртуальных машин или команды к существующим, изменение конфигураций NSG, App Services, Application Gateway, запросы на отчеты и многое другое. А далее – используется Azure Logic Apps, которые управляют данным процессом, с запросом (если требуется) подтверждений операций как со стороны ИТ заказчика, так и инженера поддержки команды Azure Managed Services. И после прохождения всех формальностей – такое электронное письмо разбирается через Cognitive Services, проверяется на предсказание возможных последствий или наличие аномалий для SLA и сами операции выполняются средствами Azure Automation, Functions и Log Analytics. Подобные сценарии я рассматривал в упомянутом ранее видео про автоматизацию управления Azure – https://youtu.be/a6VGeDUNYt4
Опять же, как и в варианте с Power Apps, на разработку бизнес-процесса требуется несколько дней, после чего уже технические специалисты заказчика остаются очень довольными простотой взаимодействия. Сразу скажу, что особым хитом сезона являются всякие там запросы на отчеты по email – написал имя виртуальной машины или ресурсной группы и даты – и получил через минуту полный почасовой отчет утилизации ресурсов ВМ.
И тут возникает правильный вопрос – а как же Level 1 Support? А вот никак, поскольку в большинстве своем Azure Managed Services – это непрекращающийся постоянный процесс модернизации инфраструктуры из наследованных технологий в облачные. И если специалист L1 не в курсе процессов и зависимостей внутри инфраструктуры заказчика – он скорее не поможет, а навредит, и при этом – базовые операции типа пресловутой «перезагрузить ВМ» уже запросто могут быть делегированы системе со службой самообслуживания, поскольку вызывая такую операцию из приложения или почты – заказчик вызывает не команду перезагрузки ВМ, а достаточно сложный скрипт, проверяющий влияние такой операции на SLA бизнес-приложений и принимающий решение уже на базе сценариев «лучшего возможного SLA».
А Level 1 – разве что приятный женский голос, отвечающий по телефону + мы начали эксперименты с Power Virtual Agents для предоставления той же информации о статусе и отчетов. А «мальчикам» из Level 1 придется либо расти до инженеров (про требования к инженеру в Azure у меня есть серия публичных собеседований – см.ниже), либо искать другую работу.
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I
И вот про то, как изменяется орг.структура организации, которая решила перейти от предоставления «традиционных» Managed Services к современным облачным Managed Services – будет третья часть данной статьи.
Igor "Walker" Shastitko 