Игры: достаем из коробки Xbox Series S, обзор и сравнение с Series X/One X, тестируем 4К картинку в WoT–первые впечатления


Вот, дождались! Новый XBOX Series S у меня в работе (вернее – играх). И даже не один, а сразу два – потому что будет еще и распаковка и обзоры XBOX Series X . Но начнем все же с более дешевой и “слабой” модели XBOX Series S, которая действительно получилась далеко не однозначной. Напомню, что Series S – это “обрезаный” вариант XBOX Series, который не дотягивает по некоторым параметрам игровой производительности не только до “старшего брата” XBOX Series X, но даже и до старичка XBOX One X.


Игры: достаем из коробки Xbox Series S, сравнение с Series X/One X, тестируем 4К картинку в WoT

Вот так выглядят технические характеристики новой младшей игровой консоли от Microsoft – XBOX Series S:

Processor
  – 8x Cores @ 3.6 GHz (3.4 GHz w/ SMT) Custom Zen 2 CPU

Graphics
  – 4 TFLOPS, 20 CUs @ 1.565 GHz Custom RDNA 2 GPU

Memory
  – 10 GB GDDR6

Memory Bandwidth
  – 8 GB @ 224 GB/s, 2GB @ 56 GB/s

Internal Storage
  – 512 GB Custom NVME SSD

I/O Throughput
  – 2.4 GB/s uncompressed, 4.8 GB/s compressed

Expandable Storage
  – 1 TB Expansion Card (matches internal storage exactly)

External Storage
  – USB 3.2 External HDD Support

Optical Drive
  – None, digital-only

Performance Target
  – 1440p @ 60 FPS, up to 120 FPS

Size
  – 275mm x 151mm x 64mm


Полезные линки

И что вам сказать про первые ощущения от XBOX Series S? Консолька получилась достаточно компактной, лёгкой (по крайней мере не ощущается тяжёлым шлакоблоком, как новый XBOX Series X и даже тот же XBOX One X), вполне себе производительной и горячей – в прямом смысле этого слова. Греется XBOX Series S очень даже сильно и слабо верится в тут красивую историю с вебкастов Microsoft, где, типа, XBOX Series S все время стоял на книжной полке позади докладчика среди книг. Он пы там с его “выхлопом” с замкнутом пространстве уже бы пожар устроил 😉 Это о том, что, почему-то, не замечают в XBOX Series S другие обзорщики и тестеры, и я бы побоялся ставить XBOX Series S куда-то в закрытое пространство во избежание – даже на ту же нижнюю полку, которая у меня есть в столике, на котором стоит телевизор. Да, там есть примерно 30см вертикально го пространства между полками, но этого явно будет недостаточно для того мощного потока горячего воздуха, который выдувает кулер. Наверное, так и оставлю лёжа у телевизора. 😉

А теперь – о самой больной теме – производительности и играх в 4К. XBOX Series S проектировался под 1440p@120fps – это максимальный режим картинки, которую он может выдавать со своими 4TFLOPS (для справки – XBOX Series X выдает 4K@120fps).Что касается 4К игр в XBOX Series S (а также видео и т.п.) – здесь есть несколько сценариев, о которых говорит Microsoft – первый – это масштабирование картинки игры с 1080р/1440р картинки до 4К (с обработкой, но некоторой потерей качества), второй – это сама игра соглашается с тем, что 4TFLOPS ей хватит для работы 4К при 30-60fps и САМА, ПРИНУДИТЕЛЬНО, включает режим работы 4K@60fps. Некоторые новые игрушки, которые разрабатывались под XBOX Series S – уже умеют работать с этой фичей. А видео – и так будет идти в 4К без проблем. Если говорить о реальных наблюдениях, то иногда масштабирование видно – простой прогон “чертиков” в World of Tanks показал, что такие артефакты масштабирования до 4К типа гребенки-лестницы вполне можно заметить на тех же границах изображений объектов – особенно, так, где идет контрастный переход – так, в начале WoT это хорошо заметно на маске пушки, а после – на краях шевронов результатов.

И что меня очень удивляет в XBOX – и что, я надеялся, пофиксят в XBOX Series S|X – это его способность работать с основными приложениями, учитывая, что поддержка клавиатур и мышек уже давно работает – почему нельзя было запустить нормальный браузер, почтовый клиент и тот же офис на очень даже производительной машинке? Типа – ввел свой аккаунт с Office 365 – и поехали. Тогда бы XBOX Series S точно оправдывал бы свою цену и позицию настоящего домашнего цифрового центра.


Обзоры предыдущих XBOX и геймпада Microsoft XBOX Elite Series 2:

  • ГадЖеТы: распаковка XBOX One X и сравнение с XBOX One S в WoT в режиме 4K HDR – https://youtu.be/JXalUSTX6jk
  • ГадЖеТы: достаем из коробки и тестируем Bluetooth на новом геймпаде Microsoft Xbox Elite Series 2 – https://youtu.be/n3AskUZWlZw
  • World of Tanks XBOX version – самоходка Dicker Max против тяжей VIII уровня – 4 убитых тяжа – https://youtu.be/-aYLGTGC96g


Семинары по AZURE–фундаментальные возможности и основы управления AZURE, использования сервисов безопасности, надежности и мониторинга в AZURE


Подписаться на канал ►►►
Мой LinkedIn ►►► 
ИТ-карьера сисадмина-2019 ►►►
Подготовка к AZ-900 ►►►
Как стать системным администратором ►►►
ИТ карьера – что для этого нужно ►►►
Еще про Azure и серверы ►►►
Про производительность дисков ►►►




По приглашению компании МУК –
https://muk.ua/ – прочитал несколько семинаров по технологиям Azure, в основном в рамках того самого базового курса по Azure, который потом предполагает сдачу сертификационного экзамена Microsoft Az-900 – http://bit.ly/Exam-Az-900 – как раз для тех, кому лениво смотреть весь цикл серий (тем более, что я их так пока и не закончил). Но, если у вас есть потребность “быстренько” познакомиться с основными концепциями и технологиями Azure всего за 4 часа, а не за 15 часов (как в моем курсе http://bit.ly/Exam-Az-900) – тогда смотрите эту “короткую” серию 😉

Темы первого семинара “Основы управления AZURE и базовые сервисы AZURE”


  • Базовые концепции облаков – надежность, эластичность, масштабируемость
  • Датацентры Azure и высокая доступность
  • Утилиты управления Azure – портал, PowerShell, CLI
  • Понятие Resource Group и развертывание ресурсов
  • Основные сетевые сервисы в Azure
  • Основные сервисы хранилищ в Azure
  • Резервное копирование и DR в Azure
  • Виртуальные машины в Azure, отказоустойчивость, мониторинг
  • Вычислительные сервисы в Azure – App Services, Functions
  • Сервисы управления процессами – Power Automate
  • Сервисы контейнеров в Azure


Azure – начальный технический обзор основных сервисов Azure – мой доклад на онлайн-семинаре MUK


Кстати, в конце видео я упоминаю про так называемое “публичное собеседование” –
https://youtu.be/pyzxPupDbI8?t=12811 – эта такое себе анонимное (по желанию) собеседование под запись или сразу в прямом эфире с разбором полетов потом – чтобы желающие сразу могли оценить требования крупной компании на простую должность типа инженера/архитектора поддержки клиентов в Azure. Потом я это опубликую тут, на канале, в разделе ИТ-карьеры – http://bit.ly/ITcarriera_ – а то народ периодически спрашивает, что нужно знать и как понять, знаешь ли ты “это” и просит записать видео – а записывать абстрактно как-то не хочется – типа, перечисления – вот, это, это и это учите, а хотелось бы сделать такой вот живой диалог, плюс – можно же сразу знать, что учить, а я еще буду в конце такого “собеседования” рассказывать, как и для чего 😉 В общем, если вы вдруг хотите поучавствовать в таком эксперименте – добавляйтесь ко мне в контакты в LinkedIn –  https://www.linkedin.com/in/iwalker2000/ и при добавлении не забудьте указать в сообщении, что хотите поучавствовать в онлайн собеседовании 😉


Смотрите продолжение моего доклада по Azure Fundamentals на онлайн семинаре, который проводит по пятницам компания МУК ( https://muk.ua/ ). Первую часть семинара можете посмотреть в записи тут – https://youtu.be/pyzxPupDbI8 – а также напомню, что у меня на канале есть 13 серий базового курса по Azure, который потом предполагает сдачу сертификационного экзамена Microsoft Az-900 – http://bit.ly/Exam-Az-900 . А темами данной части семинара по Azure для технических специалистов стали следующие возможности и функции Azure:

Темы второго семинара “AZURE – основы использования сервисов безопасности, надежности и мониторинга”

  • * Безопасность Azure
    • Защита учетных записей в Azure Active Directory
    • Политики безопасности в Azure
    • Средства защиты данных, шифрование, ключи и секреты
    • Сетевая безопасность Azure
    • Безопасная конфигурация Azure VM
    • Azure Security Center
    • Best Practices для облачной и локальной инфраструктуры с сервисами безопасности Azure
  • * Средства защиты от сбоев
    • Гео-репликация данных
    • Гео-репликация служб
    • Azure Backup
    • Azure Site Recovery
  • * Архитектурные решения
    • Мониторинг инфраструктуры Azure
    • Azure Monitor/Diagnostic
    • Базовые уведомления
    • Azure Automation
    • Azure VM/Apps Insights
    • Azure Log Analytics
    • Использования API для автоматизации мониторинга


Azure – 2я часть – по основнам безопасности, надежности, мониторингу Azure – онлайн-семинар MUK


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

Достаем из коробки "самый маленький ПК" CHUWI LarkBox на Windows 10 – Raspberry Pi нервно курит в сторонке


Заказать CHUWI LarkBox на Ali ►►► 
Магазин CHUWI ►►►
Обзор GPD P2 Max ►►►
GPD Win Max ►►►
Raspberry PI 8GB здесь ►►►
NAS из Raspberry PI ►►►
Обзор китайского миниПК/сервера ►►►
Подписаться на мой YouTube канал iWalker2000 ►►►  
ИТ-карьера сисадмина-2019 ►►► 
Подготовка к экзамену по Azure AZ-900 ►►► 
Как стать системным администратором ►►► 
ИТ карьера – что для этого нужно ►►►  |
про Azure, облачные и серверные технологии ►►► 

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

Ярким примером такого нового миниатюрного рабочего места стал мини ПК Chuwi LarkBox с процессором Intel Celeron J4115, 6ГБ ОЗУ и 128ГБ хранилища eMMC на борту, с полноразмерным HDMI портом, поддержкой разрешения 4К и возможностью установки дополнительного M.2 SSD (даже инструкция по разборке коробочки и установке SSD прилагается). И все это добро помещается в коробочке 60х60х40 мм (меньше стандартного Кубика Рубика) и весом 127г (без учета блока питания, который, в принципе – как обычная USB зарядка средних размеров).

Так что Chuwi – компания-производитель этого “чуда враждебной техники” – проделала большую работу и по “впихиванию” такого “железа” в такой корпус, и по созданию системы охлаждения, способной отвести достаточно тепла из такого малого внутреннего объема корпуса LarkBox. Кстати, я уже погонял пару тестов (видео про тестирование производительности будет обязательно, хотя особых цифр я бы не ждал, например, PCmark показал на LarkBox 1296 “попугаев”) и можно сказать, что процессор LarkBox не нагревается выше 70-75С даже при полной нагрузке в тестах, что очень даже не плохо, а температура покоя составляет около 50С. Хотя, говорят, что при установке SSD (которые тоже очень даже горячие по нынешним временам) – LarkBox начинает греться куда сильнее и даже сваливается в постоянный троттлинг.


Достаем из коробки “самый маленький ПК” CHUWI LarkBox на Windows 10 – Raspberry Pi нервно курит в сторонки


Но, вернемся к главному – месту таких мини ПК на рынке и почему Raspberry Pi нервно курит 😉 Итак, мы имеем дело с двумя устройствами примерно равной производительности “железа” и достаточно либеральными ценами. Новая Raspberry Pi 8GB, корпус с тихим кулером и к нему обвес типа подключения SSD “внутри корпуса” –  обойдется вам примерно в 130уе, тогда как при пред-заказе на IndieGoGo данный кубик LarkBox от Chuwi шел по 149уе.

Если вернуться к идее приобретения новой Raspberry Pi 4го поколения с 8ГБ на борту, то главным отсылом и была как раз идея иметь простую компактную рабочую станцию-терминал, способную выполнять основные задачи по работе с Azure – работа в VS Code, Azure PowerShell, Azure CLI, Azure Portal, Azure Storage Explorer, Azure Data Studio и прочие тулы по необходимости. Что показала работа с данными утилитами на Raspberry Pi 8GB – да ничего, большая часть из них просто не работает с Raspberry, не зависимо от установленной ОС – просто никто не портировал сборки – исключение составляет только PowerShell Core 7.x, который Microsoft лично портировала на Raspberry – все остальные утилиты или вообще отсутствуют/не устанавливаются/не запускаются, либо работают из рук вон плохо – например, VS Code, который портирована на Raspberry Pi энтузиастами под названием Code-OSS, которая глючит и в работе, и с расширениями, и производительность оставляет желать лучшего. И да, портал Azure на “местном” Chrome Raspberry Pi также работает очень-очень медленно, я бы даже сказал – мучительно медленно.

А вот то, как “бегает” и реагирует Chuwi LarkBox в интерфейсе, браузере, приложениях очень даже шустро. Я уже писал, что в PCmark 10 LarkBox показал результат 1296, что всего на 50% медленнее того же GPD Win 2 с его m3-7y30 процессором или в 2.5 раза медленнее модного игрового мини ноута GPD Win MAX . Так что в сочетании с 6ГБ ОЗУ достаточно для выполнения LarkBox всех перечисленных выше рабочих задач. В принципе – по работе с порталом Azure вопросов вообще нет, я уже погонял и все открывается с привычно по другим ноутам – типа GPD P2 Max – скоростью. Так чт, похоже, Raspberry Pi с появлением устройств типа Chuwi LarkBox потеряет массу своих поклонников-любителей дешевого “железа” для базовой работы, а вот для “китайцев” типа Chuwi наступят времена косить бабло путем замены на офисных столах “огромных NUC” на аккуратные миниатюрные коробочки – если, конечно, смогут доказать надежность и качество поддержки.

А дальше – будут тесты производительности и различные обзоры новой “игрушки” CHUWI LarkBox

И еще линки на портативные ноуты от GPD, которые у меня в использовании:

  • Портативный игровой мининоутбук-консоль 5.5″ GPD Win – 2016 год на Intel Atom – http://bit.ly/GPDwinplay
  • Портативный игровой мининоутбук-консоль 6″ GPD Win – 2018 год на Intel Core m3 7th gen – https://youtu.be/Knq2ytzxE4g
  • Производительный мини-ультрабук 9″ GPD P2 MAX – http://bit.ly/GPDP2max
  • Обзор GPD Win MAX:синтетические тесты 8″игрового мини ноута и сравнение с “настоящим” игровым ноутом – https://youtu.be/spyA4RilU8k

Обзор GPD Win MAX: синтетические тесты 8" игрового мини ноута и сравнение с "настоящим" игровым ноутом


Заказать GPD Win Max ►►►  
Предыдущая посылка с Ali ►►►
Собираем NAS из Raspberry PI ►►►
Обзор китайского миниПК/сервера ►►►
Обзор GPD P2 Max ►►►
Подписаться на канал ►►►

Продолжаю изучение нового 8″ игрового мини ноутбука от GPDGPD Win MAX, распаковку которого можете увидеть тут, а теперь – смотрите сравнительные синтетические тесты GPD Win MAX и других ноутов и планшетов – как на других платформах от GPD, так и других производителей, но уже на 10м поколении Intel Core. А поскольку GPD начало позиционировать данный GPD Win MAX, как универсальный игровой ноут (в отличие от миниатюрного GPD Win 2 – который был направлен на казуальные игры и эмуляторы страрых платформ) – то я решил сравнить GPD Win MAX не только в GPD Win 2, GPD P2 Max (моим основным мобильным рабочим ультрабуком) и Microsoft Surface Pro 7 (который на той же серии процессора, что и GPD Win MAX), но и с другими “нормальными” игровыми платформами, которые у меня есть – моим минисервером на Core i9-9900 с Nvidia GTX 1650 4GB (про него здесь) и настоящим игровым ноутом Acer Predator Helios 300 – с i7-9750H и GTX 1660 Ti на борту.


Обзор GPD Win MAX: синтетические тесты 8″ игрового мини ноута и сравнение с “настоящим” игровым ноутом

И что вам таки сказать про результаты синтетических тестов GPD Win MAX в PCmark, 3Dmark, GFX Bench и FinalFantasy XV benchmark? GPD с этим GPD Win Max проделала большую работу по охлаждению и повышению производительности непосредственно платформы Intel Core i5-1035G7, и даже добавила в BIOS возможности разгона процессора путем изменения его TDP даже выше максимального показателя в 25W (пробовал до 27W – благодаря мощному охлаждению – работал в тестах без проблем), НО – выше головы не прыгнешь и то, что сделал Intel кривым – Intel Iris Plus Graphic – уже не исправить. Я уже говорил в предыдущем видео, что GPW Win MAX получился очень странным устройством вне ниши – большой и тяжелый, чтобы называться мини ноутом, но при этом еще и недостаточно производительный, чтобы считаться действительно игровым ноутом. И выходит, что его удел – опять же – простые казуальные игры или WoT на минималках – но уже без той мобильности, которую предоставляет GPD Win 2. И, наверное, силы и объемы, которые потратила GPD на технологическую доточку процессора, пытаясь из ничего выжать хоть что-то – стоило потратить на то, чтобы интегрировать простенькую дискретную графику в тот же корпус. Сравнение с “минисервером”, у которого есть GTX 1650 показало превосходство последнего над GPD Win MAX в игровых синтетических тестах в ТРИ раза – при разнице в цене – в 1.5-2 раза. А Acer Predator Helios 300 обгоняет GPD Win MAX в 5-7 раз на графике – при разнице в цене в 2 раза. Т.е. реальное отношение цена/производительность у Predator в 3 раза лучше, чем у GPD Win MAX.

Но Acer Predator Helios 300 большой и тяжелый! – скажете вы… И будете правы! Но и GPD Win MAX уже не такой компактный и легкий, как GPD Win 2 (в реальности от размером как 9″ GPD P2 MAX, но куда толше и тяжелее), и он потерял ту самую “изюминку” мобильного компактного игрового мини ноута для казуала, а вот что он приобрел? Да ничего, в реальности… В том-то и самый важный вывод – на универсальный ноут GPD Win MAX еще не тянет, для большинства современных игр он явно слаб, запускать игры с Nintendo Switch в Cemu за 800уе, если можно тоже сделать на самом Switch, который будет легче и дешевле – абсурд. Вот так и получается, что лучше докинуть денег и купить бескопромисный ноут типа Acer Predator Helios 300, докинув в 2 раза, но получив в результате в 7 раз больше мощности и универсальный аппарат.

Радует только, что разрекламированный порт Thunderbolt 3 в GPD Win MAX “тащит” хорошо и в тестах подключенных Thunderbolt 3 порту NVMe дисков обогнал тот же Lenovo на 20-25% по скорости. Это дает надежду на то, что когда-нибудь можно будет все же “конвертировать” GPD Win MAX в “настольный универсальный игровой ноут” путем подключения к нему eGPU с нормальной внешней картой и дальше гонять его для того же видео.

А еще в защиту GPD Win MAX можно сказать, что он получился очень “холодным” и во всех тестах, даже самых экстремальных – оставался максимум теплым. Да и батарея с зарядкой по протоколу PD 3 очень даже живучая и быстро заряжающаяся. И про это – будет в следующих тестах GPD Win MAX.

А пока напомню линки на другие машинки от GPD, которые у меня в использовании:

  • Портативный игровой мининоутбук-консоль 5.5″ GPD Win – 2016 год на Intel Atom – http://bit.ly/GPDwinplay
  • Портативный игровой мининоутбук-консоль 6″ GPD Win – 2018 год на Intel Core m3 7th gen – https://youtu.be/Knq2ytzxE4g
  • Производительный мини-ультрабук 9″ GPD P2 MAX – http://bit.ly/GPDP2max


GPD Win MAX: достаем из коробки новый компактный 8" игровой ноутбук от GPD – GPD Win MAX – c Intel Core i5-1065G7,16ГБ ОЗУ и геймпадом


Итак, компания GPD, которая специализируется на выпуске компактных и достаточно мощных игровых ноутов и ультрабуков – выпустила новую модель – GPD Win MAX –  которую сам GPD называет развитием линейки игровых портативных субноутбуков-консолей GPD Win/GPD Win 2 (про них я уже рассказывал на своем YouTube канале iWalker2000GPD Win 2 и GPD Win), но в реальности – GPD Win MAX уже не портативный игровой субноут, а на такой себе GPD P2 MAX на стероидах, серьезно увеличившийся в размерах и весе в сравнении с Win/Win 2.


ГадЖеТы:достаем из коробки 8″ игровой ноутбук GPD Win MAX c Intel Core i5 10gen,16ГБ ОЗУ и геймпадом

Потому, смотря на лежащие рядом GPD Win 2 и GPD Win MAX, а особенно – держа МАХ в руках – возникает чувство неправильности в дальнейшем развитии этой замечательной ранее мобильной линейки. Да, “железо” у GPD Win MAX вроде как неплохое и современное – про него подробно в самом видео – но в отличие от GPD Win 2 – GPD Win MAX потерял уникальность серии ввиду своих размеров и веса. Средняя производительность GPD Win 2 в AAA-играх с лихвой компенсировалась его миниатюрностью и возможностью играть на ходу…

Фактически, GPD Win 2 – это такая себе портативная универсальная игровая приставка, на которой можно погонять и средние по требовательности к железу Windows-игры, и запустить эмуляторы старых платформ, и поработать с Windows – если очень надо (я вообще на Win 2 виртуалки запускал “в дороге”), и все это помещается в кармане и его не особо оттягивает.

А вот GPD Win MAX получился весьма противоречивым аппаратом – по своим размерам он явно не портативный – по длине-ширине Win MAX фактически как P2 MAX (и это при том, что у Win MAX экран 8”, а у P2 MAX – 9”) – только вот существенно отличается от P2 MAX по толщине и весу не в лучшую сторону, особенно – по весу… И это делает GPD Win MAX достаточно странным игровым девайсом без какой-то ниши и изюминки предыдущих GPD Win – уже и не портативный, но еще и не нормальный игровой ноутбук, на ходу держать и играть на таком ноуте, используя встроенный гемпад – уже проблематично, а использовать, как настольный игровой ноут – не достаточно производительности в сравнение с другими ноутами, у которых есть сама завалящаяся из актуальных сейчас графических карт.

Так что кроме обязательного тестирования GPD Win MAX в синтетических тестах и в традиционных играх – мне еще предстоит найти для GPD Win MAX его “нишу” в рабочих и просто развлекательных процессах. Впрочем, с рабочими процессами, где я активно использую GPD P2 MAXи так все ясно – у GPD Win MAX довольно специфические и разрешение экрана, и клавиатура, и тачпад, и вес/габариты – потому использовать GPD Win MAX как мобильное рабочее место не очень получится. С играми – будем посмотреть – покатаюсь с GPD Win MAX в метро (в Дубайском метро в “золотом вагоне” есть столики в спинках седений) и погоняю любимые игрушки на нем, в других поездках и просто дома в кресле – посмотрим, насколько это действительно удобно и какие игры подходят для такого стиля игры и производительности платформы.

Хотя, у владельцев GPD Win MAX есть еще и “план Б” для производительности устройства – по крайней мере в режиме “настольной работы” – это наличие у GPD Win MAX порта Thunderbolt 3, который позволяет подключать внешние графические карты eGPU и превращать ноут с неплохим процом Intel Core i5-1065G7 в полее мощную машинку с выделенной графиков – для игр или работы с той же графикой или видео. Правда, я пока жду, когда подобные работоспособные eGPU массово появятся в продаже – пока же про большинство имеющихся eGPU читаешь только отзывы – насколько они глючные или несовместимые с теми или иными моделями видеокарт или портами ноутов. В общем – ждите следующих обещанных обзоров.





А пока напомню линки на другие машинки от GPD, которые у меня в использовании:



  • Портативный игровой мининоутбук-консоль 5.5″ GPD Win – 2016 год на Intel Atom – http://bit.ly/GPDwinplay
  • Портативный игровой мининоутбук-консоль 6″ GPD Win – 2018 год на Intel Core m3 7th gen – https://youtu.be/Knq2ytzxE4g
  • Производительный мини-ультрабук 9″ GPD P2 MAX – http://bit.ly/GPDP2max

Миграция подписок в Azure–EA to CSP, PaYG to CSP и т.п.–часть 1, какая боль–теоретическая и политическая…


О сколько нам проблемок чудных готовит Microsoft’а дух!
И Windows, дитя ошибок трудных,
И Azure, парадоксов друг…
А.С.Пушкин, 2020

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

И эта проблема называется – миграция в Azure. Нет, не та миграция, которая Lift-and-Shift и прочие там сценарии, когда вы берете локальные сервисы и мигрируете их в Ажур – это достаточно просто и вполне понятно с точки зрения логики и бизнеса.

Речь идет о другой миграции – внутри Azure – между разными подписками. Например, вы начали с Pay-as-you-Go и проект удался и вам теперь захотелось перейти на нормальную подписку типа CSP с договором и реквизитами (а не просто платить с чьей-то кредитки). Или, как вариант, с грабительского контракта AE на CSP в Azure.

И вот тут, оказывается, вы попали… У вас будет куда больше технических проблем с миграцией между двумя подписками внутри Azure, нежели с переносом локальных сервисом в Azure. Хотя, казалось бы – чего тут сложного с точки зрения миграции – просто переписать ID объектов – поменять в строке GUID старой подписки на GUID новой – и все…

НО НЕТ! ЭТО БЫЛО БЫ СЛИШКОМ ПРОСТО! Хотя бы потому, что Microsoft, создавая Azure десять лет назад – о таком даже и не думал, пытаясь загнать всех пользователей под одну, только ему удобную бизнес-модель, а индусы, которые все это кодили – вообще не склонны к созданию качественного продуманного продукта с универсальной архитектурой для будущего развития.

ИТАК, если вы вдруг в своей организации решите перейти с одной подписки в Azure на другую (EA to CSP, PaYG to CSP и наоборот), главное, что вы должны знать – это то, что любой технический «специалист» Microsoft, который скажет вам «это просто – там есть специальная кнопочка Move» – нажали и все перенеслось без остановки – или просто не является «техническим специалистом» и никогда не выполнял миграцию EA to CSP, или просто врет – потому гоните его от себя «ссаными тряпками» и пусть возвращается, только когда мигрирует минимум десяток разнообразных подписок с разными типами объектов в них. Да и вообще, как показал опыт, у Microsoft в «полях» ни одного такого «специалиста» просто нет.

В чем реальная проблема миграции EA to CSP или Pay-as-You-Go to CSP (и наоборот)? – правильно, в абсолютной непродуманности архитектуры Azure на этот счет и массе технических ограничений Azure для такой миграции. Давайте разберемся, каких именно и как эти ограничения можно обойти:

1. Все объекты служб, созданные из образов Azure Marketplace, не могут быть перенесены из-за технических ограничений Azure. К сожалению, вы не можем проверить наличие или возможность миграции этих объектов с помощью скриптов (с технической точки зрения они являются обычными объектами Azure и отличаются только способами оплаты на уровне подписки). Итак, вы должны знать свою инфраструктуру и идентифицировать подобные объекты «вручную». Как правило, это:

a. разные виртуальные сетевые устройства, такие как F5, CheckPoint, Cisco и прочие межсетевые экраны/шлюзы/маршрутизаторы

b. предварительно настроенные виртуальные машины с приложениями сторонних производителей, такими как CRM, ERP, CMS – например, виртуальные машины с веб-сайтами WordPress и т.д.,

c. Некоторые службы, такие как шлюзы SMTP/SMS/Мобильные уведомления и т.д. – например, SendGrid для отправки электронной почты непосредственно из приложений.

2. Все службы приложений Azure (веб-сайты Azure, Azure App Services) должны быть помещены в исходные группы ресурсов (Resource Groups), в которых они были созданы. Если какая-либо служба приложений была перемещена в другую группу ресурсов, а исходная группа ресурсов была удалена – невозможно перенести эту службу приложений Azure в другую подписку. Если изначальная группа ресурсов еще существует – достаточно вернуть приложение в оригинальную группу. Это связано с ограничениями самой архаичной архитектуры Azure App Services, которая не менялась в Azure еще со времен так называемого Classic Azure – Azure App Services привязаны к так называемому «штампу» в датацентре, который на уровне объекта прописан, как web space – это строка URL, которая, кроме всего прочего, содержит в себе и имя оригинальной ресурсной группы, в которой был создан объект приложения. Проверить это можно тем же скриптом через свойство объекта приложения serverFarmId и сравнив его с именем группы ресурсов или через мастер «Diagnose and solve problems» – там есть возможность проверить, возможна ли миграция данного приложения.

3. Все связанные между содой ресурсы каждого мигрируемого объемкта должны быть помещены в одну мигрируемую группу ресурсов. Это означает, что, например, объект виртуальной, объекты сетевого интерфейса этой виртуальной машины, объект VNET, к которому подключена виртуальная машина, объекты Public IPs для этой виртуальной машины, availability set, установленный для этой виртуальной машины, все виртуальные диски виртуальной машины, диагностические хранилища, объекты резервного копирования и их хранилища и т.д. должны быть помещены в одну группу ресурсов. Типичный пример проблемы миграции – одна VNET в одной группе ресурсов и много виртуальных машин подключены к этой VNET, но размещены в разных группах ресурсов. В этом случае все виртуальные машины и связанные ресурсы должны быть размещены вместе с VNET. Если окажется, кто к той же VNET будет подключено приложение из другой ресурсной группы, то мы не сможем выполнить миграцию без простоя, поскольку у VNET есть связанный объект из другой ресурсной группы, а перенести его в мигрируемую группу ресурсов мы не можем, поскольку миграция перемещенных из оригинальной ресурсной группы приложений невозможна. Значит, перед миграцией такой ресурсной группы с VNET, к которой подключены объекты других ресурсных групп – мы их должны отключить от сети, что и создаст простои. Тоже касается и таких вещей, как VNET peering с другими сетями в других ресурсных группах, что приведет к остановке трафика между сетями и простоям.

4. Некоторые типы объектов Azure вообще не могут быть мигрированы между подписками Azure. Вот такое вот вам планирование архитектуры Azure! Обычно, в реальной жизни – это типы Backup Recovery Points, некоторые SKU общедоступных IP-адресов, старые «классические» объекты Azure, которые существуют только для совместимости, если ранее у вас были «классические» развертывания. Все эти типы ДОЛЖНЫ быть отключены от существующих объектов и удалены. Наиболее проблемной частью является тип Backup Recovery Points, поскольку он является частью резервной копии виртуальной машины, и это означает, что все резервные копии с точками восстановления должны быть остановлены перед удалением объектов точки восстановления (данные резервной копии будут сохранены). Чтобы проверить подписку на эти объекты, я написал небольшой скрипт PowerShell, который использует в качестве источника список совместимых типов Azure на GitHub (надеюсь, его будут поддерживать в актуальном состоянии, поскольку на него ведет ссылка с сайта Microsoft).

[CmdletBinding()]

param (

[Parameter(Mandatory=$false)]

[string]

$SubsID,

[Parameter(Mandatory=$true)]

[string]

$RGName

)

if($SubsID)

{

Connect-AzAccount -Subscription $SubsID | Out-Null

}

else {

Connect-AzAccount | Out-Null

}

$res = Invoke-WebRequest -Uri https://raw.githubusercontent.com/tfitzmac/resource-capabilities/master/move-support-resources.csv -Method Get

$list = Convertfrom-csv -InputObject $res.Content

$resObjs = Get-AzResource -ResourceGroupName $RGName

foreach($obj in $resObjs)

{

$resName = $obj.Name;

$resType = $obj.ResourceType;

$resID = $obj.ResourceId;

$resList = $list -match $obj.ResourceType

if($resList)

{

$i = [int]$resList[0].’Move Subscription’

if($i -ne 1)

{

Write-Host “`n`t***`tOBJECT CAN _NOT_ BE MIGRATED: $resName has type $resType ($resID)” -ForegroundColor Yellow -BackgroundColor DarkRed

}

else {

Write-Host “`nOBJECT IS SUPPORTED FOR MIGRATION: $resName has type $resType ($resID)” -ForegroundColor Green

}

}

else {

Write-Host “UNKNOWN OBJECT’s TYPE: $resName has type $resType ($resID)” -ForegroundColor DarkRed -BackgroundColor Yellow

}

}

Read-Host “`n`n`n[INFO]Finished. Press Enter…”

«Переварите» и теперь «наслаждайтесь» той херней, которую породил Microsoft с подписками в Azure! Представили себе сложность процесса миграции, при том, что вы хотите просто получить более удобную для вас схему оплаты?! Иногда, затраты на миграцию между подписками превышают экономический эффект от перехода на новую подписку (более низкие цены) в течение года… А как же, Microsoft заботится о вас и, главное, ваших денежках!

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

· Сценарии 2,3 потребуют только точного перемещения связанных объектов виртуальных машин/сетей/служб приложений в соответствующие группы ресурсов, как описано выше, на основе информации из самописных скриптов, которые рекурсивно проверяют все цепочки зависимостей. Т.е. здесь мы тратим время наших админов. НО! Есть некоторые сценарии, когда будет наблюдаться простой или недоступность ваших ресурсов при миграции. Самый типичный тому пример – это две группы ресурсов, в каждой из которых находятся «свои» ВМ, подключенные к «своей» сети VNET. А чтобы обеспечить взаимодействие ВМ в разных VNET по сети – между сетями созданы соединения – VNET Peering. В таком случае – миграция групп ресурсов будет невозможна, поскольку их VNET имеют связанные ресурсы в виде VNET в другой группе ресурсов. И для миграции – потребуется удаление VNET Peering, что приведет к отключению ВМ в мигрируемой группе ресурсов от ВМ в других группах ресурсов и простою на уровне доступности сервисов – примерно на 30 минут, как показывает опыт. После переноса группы ресурсов в новую подписку временно (или постоянно, в зависимости от плана миграции) можно установить VNET Peering между двумя сетями VNET в новой и старой подписках. Хоть что-то хорошее есть – ресурсы, находящиеся в разных подписках – могут обмениваться данными без проблем.

· Сценарий 4 – список объектов должен быть пересмотрен. Как правило, это ненужные или не важные объекты, которые не влияют на доступность решения (например, некоторые счетчики производительности / предупреждения для мониторинга) и могут быть удалены перед миграцией и воссозданы в новой подписке после миграции. Т.е. здесь мы тратим время наших админов.

· Сценарий 1 наихудший из всех, отнимает много времени при планировании и приводит к простоям решения при миграции. Есть несколько способов перенести объекты Marketplace в другую подписку:

o При помощи снимков дисков – хорошо для НЕ интенсивных операций записи в сервисах, которые обслуживаются виртуальными машинами. Создаем снимки существующих виртуальных машин, переносим снимки в новую подписку, создаем там новую виртуальную машину из того же самого образа Marketplace в новой подписке, подключаем/меняем диски новой виртуальной машины на имеющиеся снимки дисков ВМ из старой подписки. Далее начинается время простоя – если сервис имел публичные IP – нам либо нужно будет отключить публичные IP от старой ВМ и перенести в новую подписку и подключить к новой ВМ, либо поменять DNS записи. Потери данных в таком случае будут за промежуток времени с момента получения снимка.

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

o Некоторые объекты из Marketplace нельзя перенести технически – если это не виртуальная машина, а некоторые службы Azure, такие как SoftGrid. В этом случае сервис должен быть удален и заново создан / переконфигурирован в новой подписке вручную. В случае, если вызовы API / строки подключения и т. Д. Этой службы жестко закодированы в других виртуальных машинах / службах приложений – потребуется пересмотреть коды / вызовы.

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

Основной риск / проблема для миграции с EA на CSP – это объекты Marketplace, такие как Virtual Network Appliances, такие как брандмауэр / маршрутизаторы, особенно без возможности технической миграции (заблокированные поставщиком, например F5).

Давайте рассмотрим следующий действительно распространенный сценарий миграции:

1. Инфраструктура Azure имеет следующие объекты:

a. Общая VNET с разными подсетями в группе ресурсов RG01

b. Виртуальные машины в RG02 / RG03 подключены к VNET в RG01

c. Одна из виртуальных машин содержит CMS (из Marketplace) для корпоративного сайта

d. База данных SQL Azure для CMS

e. VNA F5 (из Marketplace), обеспечивающая безопасную публикацию / доступ к виртуальным машинам и подключенную к VNET

2. Соображения:

a. Мы не можем перенести F5 при помощи снимков из-за лицензионного ограничения, нам нужно пересоздать его.

b. Мы не можем перенести VNET из-за подключенного к нему F5, это означает, что мы должны отключить F5 перед миграцией других объектов.

c. Мы не можем отключить F5 от VNET, только полностью удалив виртуальную машину F5.

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

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

f. Другие виртуальные машины могут быть перенесены напрямую, поскольку они будут перемещены из своих групп ресурсов в VNET RG01.

3. Процесс миграции:

a. Переместить все виртуальные машины / SQL в одну общую RG01 (где размещена VNET)

b. Очистить / удалить все неподдерживаемые типы объектов (отключить резервное копирование и т.п.) в RG01

c. Создание снимков для CMS VM

d. Удалить CMS VM (время простоя веб-сайта CMS начинается)

e. Создать резервную конфигурацию для F5 VNA.

f. Удалить виртуальную машину F5 (время простоя для всех служб начинается)

g. Запустить стандартный процесс миграции группы ресурсов Azure (всех остальных VM, подключенных к общей VNET, от которой уже отключили VNA и CMS) в новую подписку и дождаться его завершения.

h. Создать новую CMS VM из Marketplace, подключить к перенесенной VNET и заменить ее диски на оригинальные снимки со старой подписки.

i. Создать новую виртуальную машину F5 из Marketplace, подключить ее к перенесенной VNET, подключить перенесенные Public IP (чтобы не менять DNS) и восстановить конфигурацию/правила и т.д. из бекапа конфигурации оригинала.

j. На этом время простоя закончено.

Что, после такого объяснения все стало окончательно запутано?! Так вот так оно в Azure с миграцией между подписками и есть… Немного лучше, если у вам архитектура IaaS сделана «правильно», с центральным хабом и подключенным к нему по Peering VNET’ов для отдельных сервисов/приложений – тогда ломать приходится только центральный хаб и можно переключать отдельные VNET с меньшими простоями (как я уже писал выше). Но, в любом случае – для сложной инфраструктуры миграция ресурсов между EA и CSP подписками очень даже мучительная.

«Погоди Игорь! Видел у себя в подписке кнопочку Transfer to CSP – правда, она неактивная, «серенькая»…» – скажут некоторые. И будут правы – кнопочка есть, и она неактивна. Microsoft таким образом создает нездоровую атмосферу на рынке путем «перехвата подписок» – захочет, и предоставит право какому-то «избранному» партнеру, и тот очень легко и без такой вот головной боли, описанной выше, сможет запросто «воровать» подписки клиентов у конкурентов. Подумайте, к кому из двух партнеров Microsoft пойдет клиент, чтобы перейти с Pay-as-You-Go на CSP, если у одного партнера клиенту предлагают такую головоломную процедуру миграции, а второму партнеру Microsoft за какие-то «заслуги» «подарила» кнопочку «сделать все сразу и без головняка»??? Как выбираются партнеры – Microsoft «сам решает, выбирая крупных и лучших» … Такая себе отличная лазейка для коррупции, как, впрочем, и нынешнее полностью коррупционное «человеческое наполнение» Microsoft (я про это писал уже ранее в нескольких своих постах – http://bit.ly/35YRYy4 и http://bit.ly/2REMPHh )… О чем это я? – да о том, кому из партнеров какого клиента отдать на подписку – решает только аккаунт менеджер Microsoft, на основе своих личностных предпочтений, и, естественно, уровня «подмазывания» партнером. Ведь подписка – это вообще – просто продажа воздуха, она ни каким образом не отображает технические навыки того или иного партнера. Таким образом, менеджеры по работе с клиентами Microsoft вообще избавлены от какой-либо ответственности насчет передачи подписок клиентов кому-либо – они просто выбирают «карман», в который будет платить клиент (и который будет получать процент с прибыли как реселлер), и никакой технической ответственности ни партнер, ни менеджер Microsoft не несут. Т.е., как я уже писал выше – менеджер Microsoft выбирает, кому «дать заказ» только из критерия «кто лучше его «подмазал»», а как известно, во всем мире «лучше всего подмазать» – это «отблагодарить нужного человека лично», финансово простимулировать. Это насчет вопроса «про кнопочку» …

А как же технические специалисты Microsoft, неужели они не помогут своим клиентам (даже не партнерам) в такой миграции? Опять же, я уже писал выше, что такого понятия, как «технический специалист», который реально способен решать практические вопросы и имеет практический hands-on опыт работы с теми же продуктами Microsoft – в локальных офисах Microsoft нет. Все, что знают нынешние «технические специалисты» в региональных офисах Microsoft – это заученные мантры уровня технического маркетинга, и не более. Мало того – таких специалистов нет и в технической поддержке Microsoft – пример тому, моя статья про то, как я общался с поддержкой Microsoft на предмет аутентификации пользователей в Azure Functions. А если копнуть чуть глубже, на предмет технических знаний «технических специалистов» Microsoft непосредственно о миграции между EA и CSP подписками в Azure – то там уже совсем мрак-мрачный, многие даже не знают о самой проблеме, типа – «да никаких проблем, все переносится на ура», не говоря уже о понимании ограничений и сценариях миграции – только маркетинговый посыл «у нас все работает, у нас все классно».

И тут самое время перейти ко второй части повествования про миграцию – технической. Тут искушенные в миграции между подписками люди скажут, что непосредственно перед самой миграцией группы ресурсов Azure выполняет проверку на валидность всех объектов и их связей для миграции. Но вот воспользоваться этой опцией в Azure отдельно от самого процесса миграции – для создания плана миграции и понимания блокирующих компонентов – не получится, Azure сразу после проверки начинает зачем-то сразу мигрировать ресурсы (это отдельный вопрос к индуским «архитекторам» Azure – ЗАЧЕМ?! – нельзя было разделить на 2 операции – проверка и если все прошло хорошо – кнопочка Продолжить и Отменить, чтобы оценить миграцию не отдельной группы ресурсов, а инфраструктуры в целом).

Но есть возможность создать глобальный скрипт, который проверяет все ограничения по миграции сразу – чтобы потом оценить инфраструктуру и выработать удобоваримый план миграции с минимальным временем простоя. Для этого нужно воспользоваться тем же API, который вызывает и портал Azure для проверки перед миграцией. Но если вы считаете, что вызов данного API в Azure – дело простого скрипта – могу сказать, что у меня «простой» скрипт на PowerShell разросся до 260 строк кода, а документация по API и какие-либо осмысленные примеры кода (даже отдельных важных фрагментов общего алгоритма) у Microsoft просто отсутствует.

Поэтому – читайте следующий пост, в котором я попробую немного осветит эту казуистическую «индускую логику», в которой даже простой вызов API теперь делается через …

Друге посты и видео по теме Azure и ИТ-карьеры: