Виртуализация *

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

Привет, Хабр! На связи команда виртуализации Astra Cloud. 

Мажорное обновление Astra Cloud Platform будет уже скоро (спойлер: в мае). Мы готовимся к этому основательно, но уже сейчас нам есть, чем поделиться. В частности, в составе платформы серьезно апгрейдился ключевой компонент виртуализации — ПК СВ «Брест».

Если вы администрируете системы виртуализации — этот материал для вас. Будет много про удобство, про мастера, про бэкенд и про то, как мы учитывали пожелания администраторов, когда меняли интерфейс. Готовы?)

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

Всё это — девконтейнеры! Да, мы начинаем программировать прямо в контейнере. И всё это бесплатно и без необходимости развёртывания новых сущностей в вашей организации. О такой кнопке «сделать хорошо» мы и поговорим в этой статье по мотивам моего доклада для DevOps Conf. 

← Часть первая

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

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

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

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

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

Привет, Хабр! Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для zVirt. В первой части мы определились с терминологией, обсудили основные концептуальные подходы автоматизации и сформировали образ «светлого будущего» — программно-определяемая инфраструктура серверной виртуализации на основе Terraform. Теперь пришло время обсудить проектирование самого решения. 

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

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера (или кто об этом задумывается). Мы попытаемся разложить задачу на конкретные модули и получим примерное понимание интерфейса. 

Привет, Хабр! 

Наверняка многие из вас знакомы с нашей платформой BILLmanager Enterprise. Изначально это решение развивалось как инструмент автоматизации предоставления ИТ-ресурсов и учета их использования. Но в какой-то момент платформа начала развиваться как более многофункциональное решение. К базовым функциям добавились такие фичи, как управление гибридной ИТ-инфраструктурой, полноценная оркестрация сервисов, расширенные возможности аналитики. Так появилась Clouden — платформа для управления гибридной ИТ-инфраструктурой и облаками, полноценное решение класса Cloud Management Platform.

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

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

24 контейнера на одном VPS за $30/мес: Elasticsearch, Redis, MySQL, nginx, headless Chrome, llama.cpp и еще 18 сервисов. Реальные docker-compose файлы, конфиги nginx, потребление RAM каждого контейнера и честный список того, что не работает. Сравнение стоимости с managed-сервисами в облаке.

Есть технологии, которые выбирают. А есть те, от которых уже не отказаться. Citrix — из второй категории. Он не побеждал в обзорах и не захватывал рынок агрессивным маркетингом. Он врастал в корпоративную инфраструктуру годами — тихо, глубоко и, по ощущениям многих ИТ-директоров, необратимо.

Банк с пятьюдесятью тысячами сотрудников обсуждает удалённый доступ — обсуждение начинается с Citrix. Фармацевтическая компания строит систему для клинических испытаний в двадцати странах — архитектор рисует схему с Citrix в центре. Государственное ведомство требует, чтобы данные не покидали периметр, но доступ был из любой точки — опять Citrix.

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

Хабр, привет!

На связи центр компетенций VMware "Инфосистемы Джет".

В этой статье расскажем о тонкостях подключения LUN (логических номеров устройств) из системы хранения данных (СХД) к хостам ESXi, которые управляются через vCenter Server. За прошлый год мы не раз сталкивались с проблемами у заказчиков, которых можно было бы избежать при правильной настройке. Как именно — расскажем ниже, не забывая и про теорию.

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

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

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

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

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

В этом гайде я покажу, как собрать двунаправленный бесконечный скролл с нуля. Здесь React и @tanstack/react-virtual, но сама техника — просто математика над scroll offset. Работает так же в Vue, Svelte или на ванильном JS.

Демо | Исходный код

В данной статье описывается процесс реализации песочницы для регулярных выражений с помощью платформы для контейнеризации Docker и утилит Linux. Цель - получить ограниченную среду, куда пользователь может подключиться по SSH и где у него будет минимум возможностей, чтобы он ничего не сломал, но мог свободно использовать регулярные выражения как со встроенными в среду txt заготовками, так и со своим произвольным пользовательским вводом.

Статья посвящена концепции создания и эволюции кастомизированных ИИ-агентов, определяемых как «виртуальные аватары» (ВА) человека. ВА позиционируются как постоянно обучающиеся модели, «прикреплённые» к конкретным людям и способные выполнять умственную работу, принимать рутинные решения и действовать, исходя из индивидуальных предпочтений, интересов и установок своего владельца.

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

Что же тогда останется самому человеку? Производственная деятельность, где нужна персональная юридическая ответственность человека-специалиста? Участие в социальном целеполагании? Заведомо человеческое творчество и заведомо человеческая эмпатическая коммуникация? Формулирование и передача новым поколениям ключевых ценностей общества? То есть всё то, что нельзя переложить на искусственные субъекты мышления и деятельности? Ниже поразмышляем над этими и другими интересными вопросами...

OpenStack — это ваш собственный «Self Hosted AWS». Звучит пугающе, но с kolla-ansible развернуть его можно за вечер. Рассказываю как — от ip addr show до рабочего дашборда Horizon. Гайд, которого мне не хватало на русском.

Добавляйте их не через -cdrom а вот так.
Обратите внимание на параметр "index=2". Число должно быть разным у каждого cdrom.

Привет, Хабр!

Когда выходит новая версия инфраструктурного ПО, у инженеров всегда два вопроса: «Что там интересного?» и «Не сломается ли то, что работало раньше?». Релиз-ноуты отвечают только на первый, да и то с поправкой на маркетинг.

Мы решили закрыть оба вопроса сразу. Взяли zVirt 4.5 от Orion soft, развернули на тестовом стенде и проверили все ключевые изменения, которые могут повлиять на эксплуатацию. Рассказываем, что нашли: от реально полезных фич до нюансов, о которых стоит знать перед обновлением с 4.4. Ведь в даже в «тихих» изменениях часто появляются вещи, которые потом незаметно становятся частью рутины администратора.

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

Broadcom купила VMware в конце 2023-го за 61 миллиард и перекроила лицензирование. Рынок зашевелился. Каждый второй вендор выпустил пресс-релиз про «замену VMware». Прошло два года. Полностью мигрировали 4%. Четыре процента. Аналитики прогнозируют, что к 2028-му уйдёт 35% рабочих нагрузок — не компаний, а нагрузок. Большинство организаций, даже уходя, будут жить с VMware на части инфраструктуры ещё годы. Эта статья про то, почему четыре.

Я проектирую и эксплуатирую enterprise-платформы виртуализации и VDI, и мне есть что сказать про то, как оно устроено на самом деле.

TL;DR:

1,005 миллиарда веб-страниц

25,5 часа

$462

По какой-то причине уже долгое время никто не писал о том, что требуется для краулинга большой части веба: последним обнаруженным мной источником был пост Майкла Нильсена за 2012 год[1].

Очевидно, что за это время много изменилось. Всё стало больше, лучше и быстрее: у CPU появилось намного больше ядер, на смену жёстким дискам пришли твердотельные накопители NVMe, скорости ввода-вывода которых сравнимы со скоростями RAM, существенно выросла ширина сетевых каналов, существенно расширился список типов инстансов EC2 и так далее. Но в чём-то ситуация и усложнилась: гораздо бóльшая часть веба стала динамической, а контент теперь более тяжёлый. Как поменялось состояние Интернета? Теперь узкие места стали другими, и для создания своего Google по-прежнему нужно около 41 тысячи долларов? Мне захотелось это узнать, поэтому я собрал и выпустил собственный веб-краулер¹ в условиях похожих ограничений.

Начнём не с технологий, а с причины, по которой эта статья вообще нужна.

В физическом мире USB-порт — дыра в периметре. Воткнул флешку — и у тебя либо данные утекли, либо малварь приехала, либо оба сценария одновременно. Stuxnet, обнаруженный в 2010-м (но активный с ~2007), пробил air gap завода в Натанзе — первоначально через завербованного агента, а дальше распространялся через USB-накопители. FIN7 в 2021-22 годах рассылали по почте подарочные коробки (от имени Amazon и HHS) с «флешками» — на деле это были Arduino ATMEGA32U4, эмулирующие клавиатуру и набивающие PowerShell-команды быстрее любого оператора. Конечная цель — Cobalt Strike, затем ransomware (BlackMatter, REvil). BadUSB, продемонстрированный на Black Hat 2014, показал, что любое USB-устройство может прикинуться клавиатурой и вводить команды — и VID/PID фильтрация тут не спасёт, потому что идентификаторы прошиты в firmware и перешиваются за минуту.

VDI в теории решает часть проблем: данные живут на сервере, а не на эндпоинте. Но USB-редиректор эту изоляцию пробивает — если разрешить проброс mass storage, пользователь утащит файлы на флешку ровно так же, как с физического ПК. А если не разрешить — придут люди со смарт-картами и принтерами, и скажут «нам нужно работать».

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