Миграция подписок в 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 и ИТ-карьеры:

Автоматическое развертывание Windows Failover кластеров в Azure и еще один пример неработающего публичного кода и поддержки от Microsoft


Смотри на действование Microsoft: ибо кто может выпрямить то, что Он сделал кривым? (Екк. 7:13)

Верить в наше время нельзя никому, порой даже самому себе. Мне — можно. (Старина Мюллер)

Северный пушной зверек подкрался незаметно, откуда его никто не ждал… (Работа)

Начало этой истории (которая по странному стечению обстоятельств практически совпала с другой историй про Microsoft support, о которой я писал ранее и с еще более печальной историей про бан моего курса по экзамену AZ-900 со стороны Microsoft) было драматичным… Заказчик присылает на развертывание дизайн ресурсной группы в Azure, в котором кроме всего прочего – еще и 6 Windows Failover Clusters по 2 сервака в каждом и с обычными сроками «на завтра». В принципе, все есть – ARM templates много раз деланы-переделаны, отдельные ARM template/DSC для кластеров официально опубликованы Microsoft на GitHub – https://github.com/Azure/azure-quickstart-templates/tree/master/301-storage-spaces-direct . Звоню заказчику, торгуюсь по срокам, договариваемся «на послезавтра, иншааллах». В моем отделе не принято «сетапить ручками» или сдавать заказчику непроверенные пакет ARM/DSC/PowerShell скриптов – потому день будет на тестирование «на всякий случай», хотя скрипты уже множество раз протестированы и отлажены на предыдущих деплойментах, в том числе и для этого заказчика буквально месяц назад – в общем, на 100% уверены и тестовое развертывание – это «чистая формальность»…

Ага! «Формальность»! Как же! До того момента, как следом за Microsoft с его комплектом ARM/DSC/PowerShell для развертывания кластера на GitHub не подкрался тот самый северный пушной зверек. Народ сразу взялся за дело и … смотрит на меня слегка офигевшими от прихода зверька глазами. Microsoft’овский скрипт для развертывания кластера выдает при тестовом прогоне ошибку:

“DSC Configuration \u0027ConfigS2D\u0027 completed with error(s). Following are the first few: PowerShell DSC resource MicrosoftAzure_xCluster failed to execute Set-TargetResource functionality with error message: The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: The network path was not found.\r\n The SendConfigurationApply function did not succeed. LCM failed to start desired state configuration manually.”

и деплоймент всего ARM шаблона обваливается 😦 Понятно, что «на послезавтра» сделать кластеры можно, но «ручками», а это не наш стиль – все инфраструктуры клиентов у нас хранятся в ARM/DSC/PowerShell и даже если нет полной копии сайта в Azure Site Recovery, а только бекапы – восстановление/развертывание копии инфраструктуры заказчика с наличием таких скриптов занимает от минут до нескольких часов.

И вот тут до меня начинает доходить весь круг тех проблем, которые очертил своими лапками пушной зверек, вызванный нежеланием Microsoft сопровождать и тестировать свои скрипты после очередных апдейтов (типа, мы вам их «кинули» 3 года назад и чего это вы еще недовольны?). А проблема в том, что примерно в 1/3 от всех развернутых клиентских инфраструктур у нас присутствуют кластеры и это означает, что случись сейчас что или клиенты захотят «дубликаты» – то у нас нет рабочих скриптов «быстро все повторить». В общем, «зверек» разгулялся по полной…

Быстрое изучение вопроса и поиск решения показало только то, что проблема не только у нас, но есть еще люди на просторах Интернета и даже успели опубликовать проблему в репозитории – https://github.com/Azure/azure-quickstart-templates/issues/6932 – но самое главное в данной ситуации, что никому в Microsoft проблема со скриптом на GitHub для развертывания кластера в Azure не интересна – запрос висит уже месяц и только дополнился еще одним пострадавшим… Ну не работает у людей инфраструктура в Azure – проблемы индейцев пользователей шерифа Microsoft не волнуют, Azure не требует поддержки для пользователей по мнению самого Microsoft. Кстати, и запрос к техническому специалисту в Microsoft, который привязан к конкретному заказчику «пошуршать по продуктовой команде и найти тех, кто выправит то, что сделалось кривым» – так и ушел «вникуда»… Периодически пингую «специалиста» последнюю неделю без какого-либо успеха… А что, Рождество же, Azure и проблемы могут и подождать, «ручками развернете и сконфигурите кластеры»…

Заранее предполагая такую проблему с тем, что в Microsoft об восстановлении скрипта никто и «не почешится», решил сделать запасной вариант развертывания кластеров в Azure, интегрированный в ARM template и использующий «чистый» PowerShell – разбираться, что пошло не так со сценарием DSC в «оригинальном» решении Microsoft, времени и желания не было.

Потому, пока Microsoft не пофиксит (может быть) «главный скрипт», вот вам основная идея, как автоматически развертывать кластеры в Azure через ARM с zero-touch. Да, получилось не так универсально, как в оригинале, но оно простое и понятное для всех, легко модифицируется и, главное, работает 😉

Итак, основные технические нюансы и сам код:

Первое – в Azure можно поднять только Windows Failover Cluster в режиме Storage Spaces Direct на 3 узла максимум. Кроме того, не все нагрузки поддерживаются в таком режиме в Azure, и, самое главное – цена вопроса, поскольку требуются производительные премиумные SSD диски для работы дисковой системы в режиме репликации Storage Spaces Direct в таком кластере.

Второе – чтобы развернуть кластер, необходимо, чтобы виртуальные машины, в нем участвующие, как узлы, имели частные статические IP в виртуальной сети Azure и были добавлены в единый Availability Set. ОС внутри этих ВМ должны быть добавлены в домен (кстати, если нужно только добавить ВМ в домен, то это можно сделать и непосредственно в ARM через расширение JsonADDomainExtension), на них установлены необходимые роли и службы. Это не проблема, такую работу выполняет простой PowerShell скрипт:

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd

)

#Online the cluster’s disks

Get-Disk |  Where-Object IsOffline -eq $true | Set-Disk -IsOffline $false

#install failover clustering services and tools

Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools

Start-Sleep -Seconds 5

Install-WindowsFeature FS-FileServer

Start-Sleep -Seconds 5

# generate domain admin’s credentials for domain join

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

Add-Computer -DomainName $domainname -Credential $cred -Restart -Force

Скрипт помещается в виде файла в какой-то Azure BLOB Storage (не забудьте разрешить анонимный доступ к объектам внутри контейнеров, хотя можно и заморочиться с атрибутам ресурса и указанием ключа доступа к этому BLOB) и запускается такой скрипт внутри VM из ARM template, как ресурс для создаваемой виртуальной машины с использованием extentions типа CustomScriptExtention, с указанием правильного пути к скрипту, который вы только что скопировали в BLOB (атрибут fileUris) и генерацией правильной командной строки (атрибут commandToExecute). Вот пример фрагмента кода именно ресурса (должен быть пристыкован к BМ) для ARM template:

“resources”: [

            {

“type”: “extensions”,

“name”: “CustomScriptExtension”,

“apiVersion”: “2017-03-30”,

“location”: “[parameters(‘location’)]”,

“dependsOn”: [

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname1av1’))]”,

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname2av1’))]”

              ],

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.8”,

“autoUpgradeMinorVersion”: true,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/pre-setupVM.ps1”

                  ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File pre-setupVM.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’))]”

}

}

}

]

Еще хочу обратить внимание на формирование строки для выполнения пользовательского скрипта – начинается она с вызова powershell с правильными параметрами -ExecutionPolicy Unrestricted и указанием имени файла вашего скрипта в параметре -File.

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

Третье – и вот тут, после выполнения скрипта и перезагрузки каждой машины начинаются проблемы. ARM считает свою работу по запуску скриптов выполненной и, самое главное, в описание каждой из виртуальной машины в ARM template вы можете добавить только один ресурс типа extensions/CustomScriptExtension. А после перезагрузки нам нужно запустить на одном из узлов будущего кластера еще один скрипт, который сформирует кластер. Сделать это в ARM template нельзя – второй скрипт не указывается, и объяснить ARM, что после перезагрузки на машине стартует еще один скрипт и окончания его работы тоже нужно дождаться – тоже не получится… Потому – занимаемся «лайфхакингом». Если нельзя сделать внутри ARM template, это можно сделать в скрипте PowerShell, который запускает развертывание ARM template. Схематически такой скрипт выглядит следующим образом:

  1. Запускаем команду PowerShell на развертывание ARM – New-AzResourceGroupDeployment с указанием файла «большого» ARM, который развернет всю требуемую инфраструктуру и запустит на требуемых виртуалках скрипт конфигурации машины (выше);
  2. А теперь «хак» – для каждой из виртуальных машин, где уже был выполнен скрипт, запускаем команду по удалению расширения, что позволит выполнить еще одно развертывание ARM со вторым скриптом, который и сконфигурирует кластер – Remove-AzAMCustomScriptExtention . Единственное НО тут – это то, что данная команда для каждой из ВМ выполняется достаточно долго – 3-5 минут.
  3. Снова запускаем New-AzResourceGroupDeployment – на этот раз для развертывания второго шаблона ARM, в котором для каждой второй виртуальной машины (одной из пары узлов кластера) выполняется другой скрипт, как extensions/CustomScriptExtension.

Четвертое – для работы кластера требуется кворум, который для нашего варианта в Azure реализуется с использованием Cloud Witness. Для этого требуется создать Azure BLOB Storage, получить Access Key этого хранилища и использовать ключ для конфигурирования кворума кластера в режиме Cloud Witness. Потому в логике скрипта выше появляется еще один пункт 2а, где после создания инфраструктуры и сервисов (в том числе и хранилища для Cloud Witness) и удаления первых расширений, мы получаем ключи доступа для созданных хранилищ и на следующем шаге передаем их как параметр в новый ARM template – и дальше уже внутри ARM они будут переданы в вызываемый через extensions/CustomScriptExtension скрипт PowerShell для создания непосредственно кластера.

Итого, общий код PowerShell скрипта, который будет выполнять развертывание двух ARM template, с переключением extensions/CustomScriptExtension и получением ключей хранилища:

# deploy basic infrastructure from main ARM template (defined in $templateFilePath)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath -TemplateParameterObject $Params | Out-Null

# delete CustomScriptExtension from deployed VMs (names should be defined in $deployedVMs array)

foreach($vmname in $deployedvms){

Remove-AZVMCustomScriptExtension -ResourceGroupName $ResourceGroupName -VMName $vmname -Name “CustomScriptExtension” -Force | Out-Null

}

# get storage account’s key for Cluster quorum Cloud Witness and set values in $Params object for next ARM deployment

$keys = Get-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $Params[‘storagename1’]

$Params[‘key1’] = $keys[0].Value

# deploy second CustomScriptExtension (build the cluster) from second ARM template (defined in $templateFilePath2)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath2 -TemplateParameterObject $Params | Out-Null

Теперь дело за малым – за созданием кластера.

Сам код вызова extensions/CustomScriptExtension во втором ARM template выглядит аналогично первой части (второй скрипт тоже не забудьте поместить в правильный контейнер, как и в первом случае), единственно – в параметрах скрипта передается 2 имени узлов будущего кластера и другие его параметры:

“resources”: [

        {

“type”: “Microsoft.Compute/virtualMachines/extensions”,

“name”: “[concat(parameters(‘vmName2av1′),’/customscript’)]”,

“apiVersion”: “2015-06-15”,

“location”: “[parameters(‘location’)]”,

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.4”,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/setupCluster.ps1”

                    ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File setupCluster.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’), ‘ -vmnames \”‘, parameters(‘vmname1av1′),’,’,parameters(‘vmname2av1’),’\” -clustername ‘, parameters(‘availabilitysetname1’), ‘ -clusterip ‘, variables(‘cluster1’), ‘ -storageaccount ‘, parameters(‘storagename1’), ‘ -storageacckey ‘, parameters(‘key1’))]”

                }

            }

        }

]

Пятое – чтобы развернуть кластер, скрипт должен выполняться с правами администратора домена, а вот CustomScriptExtension исполняет скрипт с правами ОС внутри виртуальной машины. Но скрипт PowerShell нельзя имперсонализировать в самом скрипте, но, как вариант, можно выполнить команду с правами администратора на удаленном компьютере через Invoke-Command. Т.е. запускаем скрипт через ARM template, передаем логин/пароль админа в скрипт, который создает идентити админа и вызывает команду через Invoke-Command с правами администратора.

Шестое – Windows Failover Cluster НЕЛЬЗЯ развернуть удаленно через Invoke-Command даже с правами администратора. НО, можно сконфигурировать удаленное исполнение команд Invoke-Command через аутентификацию CredSSP, которую предварительно надо настроить на обоих узлах с использованием пары перекрестных команд Enable-WSManCredSSP:

  • Для каждого из узлов включаем режим сервера Enable-WSManCredSSP Server -Force
  • Для каждого из узлов включаем доверие Enable-WSManCredSSP Client -DelegateComputer <имя второго узла> -Force

После конфигурации CredSSP для каждого узла появляется возможность использования Invoke-Command для создания кластера.

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

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd,

    [string]

$vmnames,

    [string]

$clustername,

    [string]

$clusterip,

    [string]

$storageaccount,

    [string]

$storageacckey

)

# create domain admin credential’s object

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

#get nodes name from parameter string like “node1,node2”

$nodesArr = $vmnames -split “,”

$n1 = $nodesArr[0]

$n2 = $nodesArr[1]

#enable CredSSP authentication for admin impersonation by remote calls

#set both nodes as CredSSP’s servers

Invoke-Command $nodesArr -Credential $cred {Enable-WSManCredSSP Server -Force}

#set current node CredSSP’s client that trusts other node

Enable-WSManCredSSP Client -DelegateComputer $n1 -Force

#set other node CredSSP’s client that trusts current node

Invoke-Command $n1 -Credential $cred {Enable-WSManCredSSP Client -DelegateComputer $Using:n2 -Force}

Start-Sleep -Seconds 5

# create cluster as domain admin with one node by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {New-Cluster -Name $Using:clustername -Node $Using:n1 -NoStorage -AdministrativeAccessPoint ActiveDirectoryAndDns -StaticAddress $Using:clusterip -Force} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# add second node to the cluster as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Add-ClusterNode -Name $Using:n2 -NoStorage} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s Storage Spaces Direct as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Enable-ClusterStorageSpacesDirect -Confirm:$false} -Authentication Credssp

Start-Sleep -Seconds 30

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Set-ClusterQuorum -CloudWitness -AccountName $Using:storageaccount -AccessKey $Using:storageacckey} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-StoragePool S2D* | New-Volume -FriendlyName Data -FileSystem CSVFS_ReFS -UseMaximumSize} -Authentication Credssp

Вот и все готово… Получилось, как я уже писал выше – куда более лаконично, нежели нагромождение кода DSC у Microsoft (который и обвалился в результате), более понятно и читаемо (хотя да, есть некоторые «странности», но это опять таки – вопросы к МС с его Invoke-Command и ограничениями для extensions/CustomScriptExtension) и, главное – оно работает, в отличие от «элитарного» кода Microsoft.

Сейчас держим про запас 2 набора файлов IaC для наших заказчиков с кластерами в Azure – один с «классическим» и нерабочим сейчас кодом Microsoft для создания кластеров через ARM/DSC – в надежде, что Microsoft таки читает запросы на разрешение проблем и хоть как-то сопровождает свой код, и второй – вот данный момент рабочий и приведенный выше.

Я уже писал про компетенцию и поддержку своих продуктов со стороны Microsoft – этот случай из той же оперы, причем тут Microsoft явно забил на свой публично опубликованный код (типа, а вот сопровождать не обещали). Так что, как сказано в предисловии к посту – верить никому нельзя и мы таки попытались выправить то, что Microsoft сделал кривым.

И да, если Microsoft не в состоянии поддерживать документацию, код и вообще – оказывать качественный саппорт – может, им стоит прислушаться к тому совету, который мне написали в комментариях к предыдущему моему посту (хотя Microsoft пошел простым путем – находит тех, кто делает это бесплатно за непонятные и совершенно эфимерные плюшки статуса MVP, который еще и довольно таки “подозрителен”, как я уже писал ранее):

Игорь, привет. По поводу твоего свежего поста – совет: предложить им сделать аналог Bug Bounty/Marketplace: за чужой хороший код и документацию платить премии.

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

Microsoft Azure Functions на PowerShell–включение аутентификации пользователя для HTTP Trigger, получаем информацию об аутентификации пользователя в коде функции на PowerShell и про “поддержку” Microsoft.


Начнем с технической части повествования – чтобы народу было интересно и полезно почитать, а уже потом перейдем к «политическо-ИТшной» – это уже по желанию, но как по мне так смешно, что аж печально… 😉

Итак, в некоем решении используются Azure Functions, написанные на PowerShell Core (потому что все мои админы знакомы и легко могут модифицировать, развивать решение при необходимости) и в качестве безопасности (аутентификации пользователей) работающие со стандартной идентификацией от Azure AD при вызове того, что называется Http Trigger, т.е. функции, имеющей свой персональный URL, по которому ее и можно запустить, передав требуемые параметры.

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

Аутентификация на базе Azure AD для Azure Functions включается в пару кликов и не требует какого-либо изменения кода самой Azure Functions – для функции вся аутентификация работает при описанном ниже сценарии «прозрачно», всю работу по аутентификации на себя берет «движок» Azure. Не путать, кстати, с опцией Identity, которая позволяет имперсонализировать сам исполняемый экземпляр Azure Functions в Azure и выполнять код под определенным аккаунтом в Azure, которому можно предоставлять разные права – чем, собственно, мы и пользуемся – используя Azure Functions для выполнения различных задач обслуживания, предоставляя толпе из L1 для выполнения базовых операций не доступ к порталу Azure и клиентским подпискам, а только к функциям, которые уже все сделают «как нужно и правильно»…

Но вернемся к аутентификации пользователей при вызове Azure Functions. Итак:

Заходим на основную страницу требуемой Azure Functions, переключаемся в закладку Platform Features, и там кликаем на опцию Authentication / Authorization

clip_image002

На открывшейся странице устанавливаем переключатель App Service Authentication в положение On и в появившемся ниже выпадающем списке Action to take when request is not authenticated выбираем опцию Log in with Azure Active Directory, а в следующем списке Authentication Providers кликаем на пункт Azure Active Directory / Not Configured

clip_image004

Откроется новое окно настроек – создания экземпляра приложения для аутентификации в Azure AD, где в Managed Mode выбираем опцию Express и далее, в появившихся ниже опциях, выбираем правильный каталог Azure AD (если в вашем профиле их несколько зарегистрировано), Managed Mode оставляем, как есть – Create New AD App – и оставляем имя по умолчанию.

clip_image006

Кликаем Ok в данном диалоге, ждем окончания процесса создания объекта, и в форме Authentication / Authorization, куда вас вернет портал, кликаем вверху на иконку Save. Опять таки – ждем окончания операции и получаем сконфигурированное приложение с аутентификацией от Azure AD. Теперь, при обращении к Azure Functions, которые зарегистрированы, как Http Trigger, Azure будет запрашивать у вызывающего пройти аутентификацию и предъявить аккаунт пользователя из указанной выше Azure Active Directory. Так что анонимные пользователи такую функцию теперь не вызовут.

НО! Такой сценарий достаточен только для «отсечения» анонимных пользователей, а вот если требуется какое-либо подобие RBAC внутри самих Azure Functions – например, пользователь аутентифицируется, но при этом часть параметров функции ему недоступна или доступ к данным внутри самой функции должен быть ограничен – здесь, увы, такая аутентификация не поможет. Да и вообще, у Azure нет толкового RBAC для Functions.

Т.е. после вызова функции вызов перенаправляется на аутентификацию в Azure AD и если все ок – управление передается на Azure Functions и нам надо теперь внутри исполняемой функции получить клейм пользователя и все атрибуты его учетной записи – ID в аутентифицирующей системе, имя, саму систему и прочие токены. При этом все это еще требуется получить в PowerShell.

И тут начинается самое интересное – хотя Microsoft со всех трибун кричит про внедрение Serverless решений, рассказывает про использование Azure Functions вместе с PowerShell для процессов автоматизации – в реальности никакой официальной документации от Microsoft, особенно фундаментальной, по теме Functions/PowerShell вы не найдете. В Интернете ее тоже нет, даже на любимом всеми StackOverflow – просто никто не использует решение, не смотря на громкие заявления Microsoft.

Нашел пару документов про работу с идентити/информацией аутентификации в Functions/Web Apps применительно к C#, но это нагромождение классов и вызовов было явно не релевантно для кода PowerShell. Чтобы понять всю глубину проблемы, стоит сказать, что ни я, ни моя команда – ни разу не девелоперы – только PowerShell скрипты для автоматизации процессов заказчиков и auto-healing, только хардкор, как, например, скриптик PowerShell на 1000 строк для правильного «развертывания всего» с соответствующими внутренностями VM. Для нас вообще удивительно, кстати, почему работа с тем же Azure Storage Queues в PowerShell пишется в 3 строки, а в C# сначала надо создать десяток классов при неочевидном выигрыше в производительности самой Functions. Но это уже лирика, а вывод простой – для людей, которые занимаются автоматизацией процессов на PowerShell, документации по разработке на сайте Microsoft совершенно недостаточно, приходится собирать по крупицам с разных источников, работать «методом тыка» или открыть тикет в саппорте. На том и порешили – продолжаем «копать» и обращаемся в саппорт.

Методом логического анализа кода («методом тыка») на C# обнаружилось, что чтобы работать cо всей информацией по аутентификации пользователя, вызывающего Functions с аутентификацией в Azure AD (как настроено выше) в PowerShell коде можно через Headers одной командой:

$Request.Headers

Ниже – представленный в JSON объект заголовка вызова Http Trigger в Azure Functions (тот самый $Request.Headers). Все поля, как на ладони и далее работаем с ними, как с обычным hashtable в PowerShell, т.е. получаем нужное значение по имени ключа (которым являются поля заголовка ниже).

clip_image008

Т.е., чтобы получить имя пользователя, его ID, его Access Token и т.п. в коде PowerShell – требуется максимум 1-2 команды:

$headersObj = $Request.Headers # get call’s headers

$username = $headersObj[“x-ms-client-principal-name”]   # get user account name

$userid = $headersObj[“x-ms-client-principal-id”]       # get user AAD ID

$userip = $headersObj[“x-forwarded-for”]                # get user IP

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


И тут начинается вторая часть истории – которая смешная и печальная, особенно в разрезе предыдущей моей истории про то, как Microsoft Ukraine заблокировала и удалила мои видео по курсу для сертификации AZ-900 по Azureпродолжения истории c Microsoft Ukraine после).

Итак, открыл я кейс в Microsoft support по данной проблеме и вот выдержка переписки:

1. Я описываю проблему

clip_image010

2. И получаю от Microsoft Support ответ, что в моем сценарии (option 1, процесс конфигурирования которого и описан выше) такую информацию получить нельзя:

clip_image012

3. Причем, получив такой ответ – я уже 100% уверен в возможности получения этих данных, просто еще не имею на руках конкретного кода. И я отправляю письмо типа – «точно нельзя с опцией 1? Уверены?» и получаю от Microsoft support еще один отрицательный ответ – нет, вы не можете получить такую информацию (причем, происходит это через 5 дней, три из которых – рабочие):

clip_image014

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

И вот тут начинается самое интересное и «смешное». Мне сразу же перезванивает (буквально в течение 15 минут, до этого отвечал только по почте и то – через сутки) сотрудник службы поддержки Microsoft, который просит поделиться с ними решением проблемы и кодом!!! Т.е. Microsoft, который до этого активно удалял мои технические видео про Azure из принадлежащей мне группы в Facebook, а потом и удалил мой аккаунт из админов – про это читайте тут и тут – теперь вдруг другой рукой просит поделиться информацией со своей поддержкой?! Серьезно?! Я должен бесплатно делать за сотрудников Microsoft их работу? Той информацией, которую Microsoft в качестве базовой просто обязан опубликовать в документации, поскольку и продукт – платный, и везде, со всяких трибун, Microsoft кричит о важности безопасности вообще и правильного кода – в частности. И уж точно этой информацией должна владеть служба поддержки Microsoft…

Чтобы вам было еще смешнее – я и сейчас продолжаю получать письма с просьбами отдать код, последнее пришло уже сегодня, 25 декабря, через 9 дней после того, как я сообщил, что задача имеет решение. Вот реально?! За 9 дней внутри Microsoft собственный отдел поддержки не смог найти техническое решение и продолжает ждать у моря погоды – поделюсь ли я кодом?!

clip_image016

И самое смешное – Microsoft за последние 3-5 лет сократил практически весь высококвалифицированный технический персонал из своих локальных офисов ввиду того, что Azure поддержки не требует, его надо только продавать, а технической поддержкой пусть занимаются партнеры «за деньги». Azure, как показывает опыт, просто за бла-бла-бла девочек из маркетинга Microsoft не продается (про это я говорю тоже в первой серии курса AZ-900), а партнеры, при таких отношении, «экспертизе», «документации» и «поддержке» от Microsoft – точно не будут вкладываться в «прибыльный и простой бизнес Azure» и не будут развивать компетенции Azure, как и клиенты не горят желанием платить деньги «каким-то партнерам», один раз столкнувшись с подобным невежеством поддержки «самого Microsoft». И, особенно, партнерам не интересно это делать, если развитие компетенций не интересно самому Microsoft и даже поддержка Microsoft не в состоянии дать ответ на простой, как оказалось, вопрос.

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

Но и это еще не все про Microsoft и поддержку Azure… Читайте в следующем посте про развертывание Windows кластеров в Azure и про официальные скрипты от Microsoft.

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

Microsoft Exam AZ-900 Azure Fundamentals–бесплатная подготовка к сертификационному экзамену, часть.02: экономика облачных технологий, вопросы по CapEx и OpEx в Azure


Продолжаю серию видео – http://bit.ly/Exam-Az-900 – по подготовке к сертификационному экзамену Microsoft AZ-900 Azure Fundamentals. В этой серии – сразу несколько небольших (вопросов на 4-5), но достаточно неприятных для ИТ-специалистов тем экзамена – Модель Shared Economy в облачных технологиях для снижения стоимости и главная экономическая фишка, под которой продаются любые “облака” – CapEx/OpEx в ИТ. Да-да, в AZ-900 есть такие вопросы, потому я в обзорном видео к экзамену AZ-900 – https://youtu.be/_2-txkA3Daw – и говорил, что для “простого” технического специалиста некоторые вопросы могут быть весьма “далекими” и совершенно непрактичными. Хотя, в реальности – оно так и есть – Microsoft предлагает “правильные ответы” согласно своей маркетинговой идеологии… Так что смотрите и запоминайте, не забудьте пройтись и по линкам.

Подписаться на канал ►►► http://bit.ly/iwalker2000_subs
Мой LinkedIn ►►► https://www.linkedin.com/in/iwalker2000/
Подготовка к AZ-900 ►►► http://bit.ly/Exam-Az-900
Как стать системным администратором ►►► http://bit.ly/ITProSysAdmin
ИТ карьера – что для этого нужно ►►► http://bit.ly/ITcarriera_
Обзор GPD P2 Max ►►►
https://youtu.be/HZfN_geAvQI
Все обзоры Windows 10 ►►► http://bit.ly/Windows10_review
Про производительность дисков ►►► http://bit.ly/Disk_perf_p01


Exam AZ-900 Azure Fundamentals – подготовка к экзамену, ч.02: CapEx и OpEx, экономические вопросы

Предыдущие видео данной серии про экзамен AZ-900 смотрите здесь – http://bit.ly/Exam-Az-900 :

  • Exam AZ-900 Azure Fundamentals – подготовка к экзамену, ч.01: общий обзор экзамена и как готовиться – https://youtu.be/_2-txkA3Daw

Azure и совместное потребление

  • Microsoft покупает много серверов сразу по цене, которая значительно ниже розничной (в реальности – Microsoft заказывает блоки у компаний типа QCT и собирает в стойки по своей архитектуре – Open Compute Project (OCP) – https://azure.microsoft.com/en-us/global-infrastructure/hardware-innovation/ ).
  • Microsoft собирает их облако, которое позволяет максимально плотно заполнить нагрузкой каждый физический сервер – 80% нагрузки на сервер в сравнении с 30% «обычной» нагрузки на сервер в организациях.
  • Аналогично – для хранилищ и сетевой инфраструктуры.
  • Microsoft перепродает «плотно упакованные» серверы по частям – в виде виртуальных машин и прочих сервисов.
  • Суммарная стоимость виртуальных машин, запущенных клиентами на таких серверах – выше стоимости всех серверов. Профит!
  • Чем больше клиентов и плотнее упаковка и выше нагрузка на серверы – тем выше профит… Есть возможность снижать цены или предоставлять доп.сервисы дешевле.
  • Про экономику облачных датацентров – http://cloudscaling.com/blog/cloud-computing/understanding-cloud-datacenter-economies-of-scale/
  • Клиент арендует по принципу «заплатил только за использование» и не нуждается:
    • В приобретении серверов и начальных крупных затратах
    • Помещении для хранения, средств энергопитания
    • Не нуждается в обслуживании физических серверов
    • Клиент быстро может нарастить мощности своих вычислений без дополнительных затрат


СapEx & OpEx в ИТ и облаках:

  • CapEx – разовые крупные покупка любого «железа», «софт», оплата проектов по строительство ЦОД (серверных комнат), разработка программного обеспечения и т.п.
  • OpEx – регулярные выплаты по потребностям – зарплата ИТ-специалистам, связь и коммуникации от провайдеров, электричество, обслуживание и комплектующие материалы, подписка на ПО и сервисы.
  • Облачные провайдеры сдают в аренду готовые сервисы (виртуальные машины или программные комплексы – например, Office 365 – это почта, взаимодействие в команде, хранилища и т.п.) с помесячной оплатой за услуги – по размеру ресурса или количеству пользователей и берут на себя все затраты по аппаратному и программному обеспечению, строительству и обслуживанию сервисов.
  • Таким образом – облако переводит для конечного пользователя CapEx в OpEx – пользователю не нужно тратить деньги на начальные инвестиции (CapEx) и он просто арендует те ресурсы, которые ему требуются, выплачивая помесячно стоимость только потребленных ресурсов (OpEx).
  • OpEx в облаках – фактически, рассрочка выплаты тех же денег, которые потратила бы компания на покупку железа и т.п. в течение 5 лет (обычно).
  • Эффективность переноса решения в облако Azure позволяет посчитать Total Cost Ownership (TCO) Calculator на сайте Azure.

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

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

  • Доклады по серверным технологиям Microsoft Windows Server – http://bit.ly/WindowsServer_overview
  • ИТ-карьера: как стать ИТ-специалистом, основные шаги для успешной карьеры в ИТ – http://bit.ly/ITcarriera_

Microsoft Exam AZ-900 Azure Fundamentals–бесплатная подготовка к сертификационному экзамену, часть.01: общий обзор экзамена и как готовиться


Подписаться на канал ►►► http://bit.ly/iwalker2000_subs | Мой LinkedIn ►►► https://www.linkedin.com/in/iwalker2000/ | Подготовка к AZ-900 ►►► http://bit.ly/Exam-Az-900 | Как стать системным администратором ►►► http://bit.ly/ITProSysAdmin ИТ карьера – что для этого нужно ►►► http://bit.ly/ITcarriera_ | Загляните на мой блог ►►► http://iwalker2000.com | Обзор GPD P2 Max ►►► https://youtu.be/HZfN_geAvQI | Все обзоры Windows 10 ►►► http://bit.ly/Windows10_review | Про производительность дисков ►►► http://bit.ly/Disk_perf_p01
 

Я уже несколько раз начинал серию “серьёзных” видео про ИТ для системных администраторов и вообще 😉 Это была и серия про ИТ-карьеру – http://bit.ly/ITcarriera_  – в рамках которой я планировал перейти от простых рекомендаций по карьере в ИТ к техническим рекомендациям, и серия про Microsoft Azure для системных администраторов – http://bit.ly/WindowsServer_overview – где я планировал рассказать про Azure с точки зрения миграции ИТ-инфраструктур и гибридных решений. И обе эти серии тихо закрылись – ввиду малого интереса аудитории к ним и больших временных затрат на их подготовку – как бы – “если людям не интересно, то чего я буду тратить на это свое время”.

И вот, я таки снова решил начать новую серию – которая будет менее абстрактной, чем предыдущая, поскольку она будет отвечать конкретным задачам – не научить некоего “Васю-будущего админа облаков” чему-то вообще, а помочь в подготовке и сдаче достаточно специфического сертификационного экзамена Microsoft – Exam AZ-900: Microsoft Azure Fundamentals (Основы Microsoft Azure). И даже если вы не собираетесь сдавать сам экзамен, то я постараюсь построить материал так, чтобы вы могли получить современные и обширные знания по облачным технологиям вообще и технологиям Microsoft Azure в частности. И да, видео не будут иметь ограничений по уровню начальных знания – их можно (и нужно) смотреть и нетехническим людям в ИТ – для расширения кругозора и понимания того, что вы продаете и с чем каждый день сталкиваетесь в повседневной работе/жизни – например, как мне сказали “Облако – это OneDrive” 😉 Нет, это один из множества сервисов, которые предоставляет облако. И да, поскольку я пообещал этими видео помочь людям – я постараюсь оперативно создавать новые и закончить всю серию, охватив все очень обширные темы экзамена. Так что подписывайтесь на канал –http://bit.ly/iwalker2000_subs – продолжение следует. А между сериями будут другие обычные видео про гаджеты и т.п.


Exam AZ-900 Azure Fundamentals – подготовка к экзамену, ч.01: общий обзор экзамена и как готовиться



Для кого это серия видео про Azure?


  • Для всех, кто планирует сдать экзамен Exam AZ-900: Microsoft Azure Fundamentals – Основы Microsoft Azure.

      – Для тех, кто планирует подготовиться самостоятельно, но им тяжело сконцентрироваться на конкретных направлениях изучения ввиду того, что материал экзамена очень обширный.
      – Для тех, кто «не дружит» с английским языком на достаточном уровне и ищет в Интернете возможность поучиться на русском бесплатно.
      – Для тех, кто ищет в Интернете брейндампы данного экзамена бесплатно 😉 но хочет еще и понимать, что он там заучивает

  • Для моих бывших коллег из Microsoft, особенно из отделов продаж, которые ходят и рассказывают, какой классный Azure
    , но потом компания потребовала всех их сдать экзамен – и они его успешно провалили и обратились ко мне за помощью (а вы думали, я вас не потроллю? %) )

  • Для всех, кто собирается работать в ИТ (даже без экзаменов) по направлению облаков, и не обязательно Microsoft Azure
    – эта серия видео будет также идти, как часть моей серии «ИТ-карьера» –
    http://bit.ly/ITcarriera_ и http://bit.ly/itcar_post1

  • А! И для моего сына, которому нужно написать в его Slovenská technická univerzita v Bratislave (STU) курсовую по введению в облака
    😉 Останется только перевести на словацкий.

  • Планы на серию? Это примерно 20-25 роликов по 30-45 минут каждый, с детальным изложением одной из тем экзамена, с ориентировочными вопросами, практическими примерами и т.п.
    – будут выходить по 2-3 видео в неделю, т.е. в общем – около 2х месяцев 😉



Особенности экзамена AZ-900


  • Экзамен абсолютно дурацкий!

  • Это не технический в общем понимании экзамен…

  • В экзамене очень много всякого маркетингового булшита от Microsoft.

  • В экзамене много теоретических и абстрактных вопросов (типа authentication vs authorization, CapEx vs OpEx)

  • В экзамене много спорных вопросов, которые сам Microsoft озвучивает по разному, исходя из ситуации – например, снижения стоимости владения потому, что не нужно столько админов? – в жизни МС руководству рассказывает, что ДА – вы уменьшите потребность в персонале, в экзамене – он же для админов – НЕТ, админов сокращать не надо!

  • В экзамене много вопросов по подпискам, лицензированию, планам поддержки и прочим.

  • В экзамене много вопросов по международным регулятивным требованиям – типа GDPR, NIST, ISO – и сервисам для государственных учреждений.



Особенности экзамена AZ-900 – Если вы ТЕХНИЧЕСКИЙ СПЕЦИАЛИСТ, который работает с Azure, то вы имеете шанс НЕ СДАТЬ его потому, что:

az900-01-05

Особенности экзамена AZ-900 – Если вы НЕ ТЕХНИЧЕСКИЙ СПЕЦИАЛИСТ, а менеджер по продажам Microsoft, или другой «эффективный менеджер», особенно новомодный миллениал – то вы НЕ СДАДИТЕ:

az900-01-06

Основные группы вопросов на AZ-900

az900-01-07

Как подготовиться к сдаче сертификационного экзамена Microsoft AZ-900 Azure Fundamentals?

  • Набраться терпения и просмотреть все видео этой серии 😉
  • У меня на канале еще много видео по теме Azure, особенно здесь – http://bit.ly/WindowsServer_overview и здесь – http://j.mp/Azure_IaaS_2015
  • Подписаться на мой канал, поставить лайк и перешарить эти видео в соц.сетях – это +100 в карму, а карма, как известно, очень помогает на экзамене.
  • Почитать рекомендуемую литературу (см.дальше) и различные источники – я первоисточниками для подготовки буду делиться в следующих, более практических видео по AZ-900.
  • Официальные курсы? Если хотите – идите. Все зависит от самого тренера – как повезет. В мою бытность тренером я подстраивал материал курса под реальные вопросы экзаменов, потому как сам материал курса не предназначен для подготовки к экзамену.
  • Брейндампы? Да, если найдете – сейчас это очень прибыльный бизнес и «бесплатных» найти проблематично, тем более – с комментариями и рекомендациями.
  • Практическая работа – без более-менее внятного представления, как же выглядит Azure Portal и чем отличается Virtual Machine от Web App, сдать будет проблематично.
  • Начните с создания бесплатной подписки и страницы https://azure.microsoft.com/en-us/get-started/

Список книг для самоподготовки к экзамену AZ-900

  • Exam Ref AZ-900 Microsoft Azure Fundamentals – собственно, материалы официального курса Microsoft
  • Learn Microsoft Azure
  • Azure: Microsoft Azure Tutorial for Beginners
  • Microsoft Azure For Beginners: Getting Started with Microsoft Azure
  • Azure: Microsoft Azure Tutorial The Ultimate Beginners Guide
  • Hands-On Cloud Administration in Azure: Implement, monitor, and manage important Azure services and components including IaaS and PaaS

Новые Microsoft Surface – телефон Surface Duo, складной планшет Surface Neo, Surface Pro X на ARM


Итак, Microsoft, на прошедшем в среду, 2 октября 2019, мероприятии, посвященном своим новым устройства линейки Microsoft Surface, презентовала целую гамму новых устройств, которые, фактически, полностью закрывают всю инфраструктуру лептопов и мобильных устройств – лептоп Microsoft Surface 3, профессиональный планшет Surface Pro 7, его облегченную версию на ARM процессоре Surface Pro X, новый и ожидаемый складной планшет Surface Neo (ранее называемый Centaurus), работающий с новой версией Windows – Windows 10X – облегченной и “заточной” под работу с двумя экранами и, совершенно неожиданно – новый телефон-раскладушку с двумя экранами 5.6″ и под управлением Android с глубоко модифицированным UI – Microsoft Surface Duo. Также Microsoft показала беспроводные наушники-вкладыши, от одного вида которых хочется сказать НЕТ!, а услышав цену в 250уе – НЕТ, НЕТ И ЕЩЁ РАЗ НЕТ! НО – вернёмся к обзорам всех этих традиционных Surface Laptop 3, Surface Pro 7, Surface Pro X и раскладушек Surface Neo и Surface Duo.


Новые Microsoft Surface – телефон Surface Duo, складной планшет Surface Neo, Surface Pro X на ARM


Surface Laptop 3 –
https://youtu.be/eITjrh267vs?t=189 – довольно проходной девайс, здесь интересно то, что Microsoft вместе с AMD создал для новых моделей специальный процессор AMD RYZEN Microsoft Surface Edition, пересмотрел концепцию ремонтопригодности и замены комплектующих, расширил линейку моделью с большим размером экрана – 15″ и убрал эту ужасную тряпку на клавиатуре 😉 В общем – такой себе качественный и не очень дешевый ноутбук премиум класса с очень высокой ценой – https://www.microsoft.com/en-us/surface – цены появились на сайте МС уже ближе к утру – с максимальным ценником в 2900уе за i7/Ryzen R7 и 32ГБ ОЗУ – не взлетит, я думаю…
 

Еще более “проходным” оказался Surface Pro 7 –
https://youtu.be/eITjrh267vs?t=577 – улучшения настолько “бедные”, что даже сказать нечего… Типа, “ну вот мы добавили USB Type-C, и поменяли процессор, и…, и… – ах, ну да, новое перо, а еще мы пофиксили Эксель и теперь пером можно писать прямо в ячейках”…. Вау!!!! 😦 Но, надо отдать должное серии Microsoft Surface Pro – его улучшать – только портить. Достаточно просто менять компоненты. А так, начиная с Surface Pro 3 – шикарный девайс, пользуюсь уже 5 лет без всяких нареканий (кроме сдыхающей батарейки) – https://youtu.be/aI6He06ZHY8



Microsoft Surface Earbuds – таблетки АСС в уши? За такую цену? Нет и еще раз НЕТ!



Microsoft Surface Pro X – https://youtu.be/eITjrh267vs?t=844 – это, конечно, что-то такое, что очень хочется посмотреть и пощупать! Легкий и тонкий – при 13″ экрана и … полноценной Windows 10, но на ARM процессоре, который Microsoft разработал совместно с Qualcomm на базе их процессора Snapdragon 8cx – теперь это называется Microsoft SQ1 и имеет на борту модуль AI в 9TFLOPS. Слушая выступление, у меня сложилось чувство, что Microsoft и сам не знает, нафига в таком планшете такой модуль и как его использовать в реальных задачах – пример интеллектуального улучшения картинки в рельном времени как-то не очень нагляден. А вообще – при таком ценнике – МС решила не конкурировать с другими моделями Microsoft Surface Pro – и выставила одинаковый ценник и на Pro 7, и на Pro X – https://www.microsoft.com/en-us/p/surface-pro-x/8vdnrp2m6hhc – такой планшет выглядит очень привлекательно для тех, кто много бывает в разъездах. Кроме того – очень интересны мелкие инновации – типа стилуса, для которого предусмотрены контейнер и беспроводная зарядка прямо в клаве. В общем – это тот момент, когда количество переходит в качество, но, правда, не то, которое бы хотелось лично мне. Про свои “хотелки” к мобильным устройствам я писал тут – http://bit.ly/FutureGadgets01



И новые ультрамобильные устройства c двумя экранами в линейки Microsoft Surface – планшет-раскладушка Microsoft Neo – https://youtu.be/eITjrh267vs?t=1350 – под управлением Windows 10X (про которую никаких реальных деталей так и не рассказали – хотя бы потому, что она еще “не совсем готова”) и раскладушка-телефон Microsoft Duo – https://youtu.be/eITjrh267vs?t=1777 – этот под управлением Android с переточенной под работу с двумя экранами оболочкой от Microsoft (кстати, кто не вкурсе, у Microsoft есть отличный Microsoft Launcher для Android – пользуюсь им и очень доволен).

“Икспёрды” уже начали крик “зачем нам 2 экрана, что с ними делать?!” – хотите или нет – но 2 экрана и раскладушки – это тренд 3-5 лет – а для меня постоянная реальность, поскольку раскладушками – пусть и с экраном и клавой – пользуюсь все годы своей мобильной эпопеи… И могу сказать, что более продуктивного мобильного устройства, чем телефон-раскладушка с аппаратной клавой (или, как предлагает Microsoft – вирутальной, но все же привычной, в стиле мини-ноутбука) – лучший рабочий телефон.

Кстати, Microsoft на протяжении всей презентации говорила, что создает устройства для креативной части населения, которая будет создавать тот или иной контент при помощи их устройств. Я, кстати, создаю создаю контент в виде текста – по дороге на работу/с работы, в роскошном “золотом классе” метро Дубаи – можно отлично поработать 40 мин, чем я и пользуюсь – на ноутбуке не очень комфортно, а вот на мобиле-раскладушке Gemini PDA 4G или теперь – на мини ультрабуке GPD P2 Max – очень даже хорошо получается поработать. Например, этот текст и был как раз написан в метро по дороге на работу – как и многие другие – будь то документы или книги. 1.5 часа каждый день для креатива – это же отлично! Вы так не делаете, просто скролите картинки – вы не просто созданы быть креативным, вы только потреблять… Winking smile Большинство упомянутых выше “икспёрдов” – как раз из такой категории. Так что если вы ничего не создаете – вы для Microsoft – просто лишний баланс, поскольку не относитесь к креативному классу и устройства Surface – точно не для вас. Продолжайте молча, потреблять, а не рассуждать, кому же нужен телефон с двумя экранами – просто ввиду ограниченности вашей жизненной модели – вы даже не можете понять его назначение… Winking smile

Понравилось ли что-то из продемонстрированного Microsoft лично мне и что бы я себе купил?

Как я уже писал выше – очень интересно выглядит на презентации Microsoft Surface Pro X, хотя окончательное решение о покупке я бы принимал, только подержав Surface Pro X в руках и глянув на его экран. Вопрос вызывает и ARM архитектура процессора Surface Pro X, и, не смотря на заявления Microsoft о том, что там работает “полноценная” и “полностью совместимая” сборка Windows 10 – я бы все же протестировал бы некоторые приложения, работа которых может быть под вопросом.     

Microsoft Neo? Да, очень интересно, учитывая, что он появится только в следующем году – я успею “укатать” мой нынешний мини ультрабук GPD P2 Max – и с чистой совестью перейти на Microsoft Neo. Надеюсь, к тому времени его уже доведут до ума и хорошо попатчат, особенно новую ОС, а наличие нового процессора Intel 11 поколения как раз оправдывает такую покупку – сразу с Core m3-8100Y на 11 – отличный апгрейд. И, конечно же, еще хотелось бы клаву и стилус. То, что Microsoft придумал с совместным использованием аппаратной и виртуальной клавы/экрана в Surface Neo – выглядит куда интереснее и правильнее того же TouchBar в MacBook – куда больше сценариев применения. В общем – осталось подождать полгодика – и брать Winking smile

Microsoft Duo? я не уверен… Сейчас у меня отлично с поддержкой моего креатива справляется Gemini PDA 4G и мне очень нравится его аппаратная клавиатура. Именно аппаратная QWERTY – лучший инструмент для работы с текстом, даже круче двух экранов Winking smile. Хотя ему уже больше года, новый вариант Gemini – под названием Cosmo – не не особо нравится, так что, может, после выхода в следующем году пощупаю Microsoft Duo тут, в Дубаи (если буду продолжать жить и работать тут) и прикуплю себе. Особенно, если они добавят и в Microsoft Duo вариант аппаратной клавы-вкладыша, как у Microsoft Neo.

Что же разочаровывает в Surface Duo и, впрочем, в Surface Neo – это опять замкнутость на одном устройстве – печально, что никто не сказал ни слова про сценарии работы, подобные Continuum в Windows Mobile 10 – было бы очень круто иметь возможность использовать эти маленькие, но мощные устройства в режиме “обычного” десктопа – по проводам или без. И да, так классно начавшаяся тема того, что называется простым доступом к компонентам и возможность замены хранилищ в Surface Laptop 3 и Surface Pro X – не нашла продолжения в Surface Neo и Surface Duo. И тут я снова возвращаюсь к теме, “почему для меня Microsoft Duo – не “ВАУ!”?” – да потому, что устройство все же не стало изменением существующей на рынке парадигмы “все в одном – а потом просто выкините”… Sad smile Думаю, пора снова в руки брать Gemini PDA и на его аппаратной клаве настрочить новую статью про будущее мобильных гаджетов, развитие старой – http://bit.ly/FutureGadgets01 – с учетом современных реалий. 


И обзоры других гаджетов у меня на канале iWalker2000:

СофТы: как в Windows 10 вернуть планы управления питанием Ultimate Performance, High Performance


Тут в видео про мой новый ультрабук GPD P2 Max и его тест батарейки некоторые очень внимательные личности разглядели, что у меня больше различных опций настройки планов управления энергопотреблением Windows 10, чем у них 😉 У меня есть такие планы, как Ultimate Performance, High Persormance и даже Power Saver к стандартному Balance Performance в новых сборках Windows 10. Как так? И как включить все эти планы себе?

Подписаться на мой канал iWalker2000 ►►► http://bit.ly/iwalker2000_subs |
Купить GPD P2 Max ►►►
http://bit.ly/2ktSUZ0 |
Магазин GPD – проверено покупками ►►►
http://bit.ly/2PrZPke |
Мой LinkedIn ►►►
https://www.linkedin.com/in/iwalker2000/ |
Обзор Acer Predator Helios 300 ►►►
https://youtu.be/P-YFuA6ZmyY |
Все обзоры Windows 10 и полезных системных утилит ►►►
http://bit.ly/Windows10_review |
Azure для сисадминов ►►►
http://bit.ly/Azure_IaaS_p04 |
Про производительность дисков – как оценить скорость диска и как разогнать ваш ПК ►►►
http://bit.ly/Disk_perf_p01 |
Как стать системным администратором ►►►
http://bit.ly/ITProSysAdmin

В действительности – примерно 2 года назад, с очередной осенней сборки Windows 10, Microsoft решил, что выбор плана управления энергопотреблением для лептопов под Windows 10 – слишком сложная вещь для понимания простым пользователем и поэтому – скрыл для доступа все привычные планы, оставив для совместимости только Balanced Performance и добавив в диалоговое окно управления питанием (то, что вы видите при клике на иконку батарейки в панеле таскбара) переключение режимом от Best battery life до Best Performance – но при этом Windows 10 будет балансировать работу в пределах достаточно зажатого по производительности Balanced Performance. Но для многих – ручной выбор планов энергопотребления остается актуальным – хотя бы потому, что они знают, что это такое и им все равно, как долго проживет батарейка, особенно, когда ноут больше 70% времени проводит на зарядке, зато хочется получить чуть больше производительности – и переключение на High Performance и Ultimate Performance планы очень даже поможет.


СофТы: как в Windows 10 вернуть планы управления питанием Ultimate Performance, High Performance


Так вот, Microsoft пока не отключил полностью в Windows 10 все эти планы, а только “припрятал” их и восстановить их видимость в списке – не проблема, нужно только запустить командную строку (или PowerShell) и выполнить следующие команды, которые создают “правильные” дубликаты нужных планов в вашей Windows 10:


Для включения Power saver
powercfg -duplicatescheme a1841308-3541-4fab-bc81-f71556f20b4a


Для включения High Performance

  powercfg -duplicatescheme 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Для включения Ultimate Performance
powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61


После дубликации можете убедиться в том, что все планы на месте, использовав команду powercfg /L и включив нужный план прямо из командной строки, скопировав его ID из списка и использовав в команде powercfg /S {Plan ID} , чтобы потом не лазить по настройкам.


И еще пару слов насчет батареи в ноуте, который постоянно стоит на зарядке – недавно на моем корпоративном ноуте Lenovo Thinkpan T480, который 80% времени проводит на зарядке, отрубилась внутренняя батарея. И на этот счет Lenovo на своем сайте саппорта рекомендует установить приложение Lenovo Vantage и в нем настроить Battery Charge Threshold с ограничением по максимальной зарядке в 90-95% – это позволяет сохранить батареи ноута “вечно молодыми”…

И обзоры других гаджетов у меня на канале iWalker2000: