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

Современная бэкенд‑разработка не обходится без средств контейнеризации. Самому простому приложению, скорее всего, будет нужна хотя бы база данных или пучок дополнительных зависимостей из веб‑серверов, балансировщиков, сборщиков логов и метрик. Для быстрого их развёртывания и настройки используются кастомные или готовые образы и контейнеры. И когда разговор заходит о контейнерах, первое, что приходит на ум, — это Docker и Dockerfile.

Для многих это стандарт, отклонения от которого вызывают недоумение и вопросы. Но даже у всего хорошего есть альтернативы. Одна из них — Nix. Насколько она сопоставима по удобству и скорости с Docker?

Меня зовут Борис Табачников, я разработчик отдела RnD в СберТехе. Кратко расскажу, что такое Nix в целом, зачем вам его использовать и подробно сравню скорость работы Nix и Docker.

Статья будет полезна DevOps‑инженерам и разработчикам, интересующимся контейнеризацией. И особенно — тем, кто ищет альтернативы для Docker и кого заинтересовал Nix, но при этом сферы его использования и применимость для сборки образов недостаточно понятна.

Удивительно, но о проекте OpenSDN (прямом наследнике Tungsten Fabric) на Хабре написано не так много. Однако в последнее время этот проект набрал популярность. Например, за год сообщество активных пользователей платформы OpenSDN организовало инфраструктуру для сборки и рецензирования исходного кода, наладило обмен информацией (в группе в Telegram, на сайте проекта, в разделе на GitHub и пр.), выпуск новых версий программы и дальнейшее использование для решения бизнес‑задач.

В этой статье вы найдёте подробный рассказ об OpenSDN: что это такое и как работает, почему всё больше компаний выбирает этот проект для управления сетью, а также как ИТ‑холдинг Т1 и Т1 Облако участвуют в развитии сообщества и технологии.

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

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

Мы использовали Python, VirtualBox, JSON и PowerShell, чтобы тесты запускались в чистой среде, результаты были понятны всем, а интеграция с разработкой максимально простой. Архитектура гибкая, удобная и кроссплатформенная.

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

Привет! Меня зовут Кирилл, я инженер по разработке инфраструктуры в компании YADRO. Представьте: вы разработчик программного обеспечения в крупной компании и вам потребовалось создать новую виртуальную машину. Как это сделать? Пожалуй, многие ответят, что можно запросить ее через отдельную задачу на ответственную команду DevOps-инженеров, потом подождать, пока за нее возьмутся и вручную создадут ВМ с помощью OpenStack.

Звучит просто, но это только часть пути. От глаз разработчика скрыты шаги по добавлению ВМ в inventory, определению нужных конфигурационных параметров, прогону ansible-ролей и сопутствующей настройке. Иногда и на этом процесс не заканчивается, ведь люди привыкли пользоваться доменными именами, а не ip-адресами. Вручную этот процесс занимает много времени и не лишен влияния человеческого фактора, поэтому возникает необходимости в автоматизации.

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. К сожалению, достаточно подробной инструкции по работе с ВМ через OpenTofu на просторах интернета найти не удалось, поэтому я и решил создать ее сам, сделав акцент на широте возможностей инструмента.

Жизнь в ИТ не простая, работа, таски, дедлайны, мониторинг серверов, случайные падения кластера среди ночи... и где-то в этом хаосе есть ещё и личная жизнь. Проблема в том, что если в проде у тебя всегда есть система мониторинга, то в отношениях её нет. Или есть, то только в виде пассивно-агрессивного вопроса перед сном "Тебе не кажется, что ты мало времени уделяешь семье?".

Поэтому, сейчас мы разберёмся как можно сделать Kanban-доску в Taiga и попробуем сделать из хаоса порядок. Ведь мы можем поддерживать 99.99% аптайма в проде, почему бы не попытаться добиться хотя бы 80% в личной жизни?

В 2005 году выбор технологии Fibre Channel для корпоративной инфраструктуры был очевиден: скорость, высокая надежность, специализированное оборудование, поддержка производителей. FC доминировал в корпоративном сегменте, предлагая целостное решение для передачи данных с интегрированными механизмами отказоустойчивости, балансировки нагрузки и управления трафиком. Решение привлекало внимание и более мелких компаний, однако его широкому распространению среди них препятствовала высокая стоимость оборудования и обслуживания.

Почти 20 лет спустя ситуация меняется. Технологии на базе Ethernet догнали FC по функциональности, а в некоторых аспектах опередили его в развитии. Ethernet уже предлагает скорость в 100 Гбит/с в массовом сегменте, а на горизонте маячат 400-гигабитные системы.

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

Привет, Хабр! Меня зовут Илья. В этой статье я продолжу своё повествование о российских почтовых системах, а именно расскажу об особенностях взаимодействия и интеграции почтовых систем с каталогом LDAP.

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

В этой статье я хочу рассмотреть факторы, которые, по моему мнению, способствовали упадку VMware, с упором на влияние Broadcom и непомерно выросшую, по сравнению с конкурентами, стоимостью лицензий. Отдельно хочу сказать, что все это — моя личная оценка ситуации.

Наша команда системного программирования YADRO продолжает работать с open-source эмулятором QEMU.  В этой статье я расскажу, как и зачем мы создали виртуального двойника Intel NTB Gen3.

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

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

В условиях ограничения доступа к самым современным технологиям компании всё чаще стремятся переложить заботу о поддержании работоспособности ИТ-инфраструктуры на профессионалов. И вариантов тут два: либо консолидировать вычислительные ресурсы на собственной технологической площадке, развитием которой будут заниматься своя ИТ-служба, либо отдавать вычислительные ресурсы на аутсорсинг, то есть пользоваться услугами облачных провайдеров. Проще, конечно же, доверить управление ИТ-инфраструктурой сторонним профессионалам, однако надежнее и безопаснее развивать собственные компетенции за счет внедрения современных средств автоматизации управления Центрами обработки данных (ЦОД).

Сталкивались ли вы в вашей компании с проблемами?

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

Если да, то эта статья для вас!

Здравствуйте уважаемые коллеги! Прежде всего я хочу Вас поздравить с прошедшим Новым Годом и Рождеством и в НГ пожелать Вам спокойствии и мирного неба над головой!

В то время, когда кто-то праздновал, кушал салатики и веселился, мне было не до веселья, т.к. на утром 2е января был намечен переезд из ЦОДа в ЦОД, что накладывало существенные ограничение на количество выпитого согревающего (хотя я не пью), ко так-же на распорядок дня 1го января. Нужно было перед выключением еще раз все проверить и перепроверить, но об этом чуть позже.  

В ряде прошлых материалов, а именно

Выбор ЦОДа в Санкт-Петербурге, ЦОД
Переезд в ЦОД
и
Переезд в ЦОД, Выбор ЦОД
я затрагивал не только аспект выбора ЦОДа, подготовку к перееду и сам переезд.

В одной из последних статей Резервный ЦОД? | Мастерская IT решений были выведены тезисы о том, что резервный ЦОД — это не только показатель зрелости компании, её уверенности в масштабировании ресурсов, безопасном хранении данных, но это и аспекты репутации компании перед акционерами, собственниками, партнерами и клиентами.

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

На хабре уже было несколько статей, посвящённых технологии NVME over Fabric, которая в последнее время становится всё более популярной для сетевых дисковых подключений. Мы сейчас строим некую новую систему и у меня возникла мысль протестировать и сравнить несколько различных настроек. Возможно, кому-то из коллег будут полезны полученные мной результаты.

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

Эти истории сподвигли меня на то, чтобы разобрать проблему безопасности виртуальных сред с помощью методики ХардкорИТ. Конечно, время вспять мы не повернем, но помочь героям наших кейсов и другим компаниям избежать подобных атак в будущем — вполне. Подробности под катом!

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

Меня зовут Александр Еремин, и я руководитель практики серверной виртуализации К2Тех. В этой статье вместе с моим коллегой Аскаром Добряковым из К2 Кибербезопасность я расскажу о восьми российских платформах виртуализации с сертификатом ФСТЭК. Вы узнаете об особенностях каждой платформы, их сильных сторонах и ограничениях. Также разберем, какие решения подойдут для разных организаций и задач. Статья будет полезна техническим специалистам и руководителям, которые планируют внедрять защищенную виртуализацию. 

Представленный ниже текст — это попытка систематизировать подход к ПО серверной виртуализации как в целом, так и в части отечественных продуктов. Я как сотрудник «ЛАНИТ‑Интеграции» постарался подойти к вопросу не с точки зрения количественных и качественных показателей (как когда‑то сравнивали циферки максимумов VMware vSphere и Microsoft Hyper‑V), а со стороны потребностей заказчика. Наверняка многие вопросы, которые будут здесь затронуты, вам знакомы. Может, вы уже давно продвинулись дальше в своих изысканиях. Что ж, в таком случае это лишний повод для вас поделиться своими мыслями с сообществом.

Всем привет. Данная статья не более чем эксперимент. Тем более, что сейчас есть тренд на запуск баз данных в контейнерах т.к. это действительно производительнее и нет лишнего оверхеда в сравнении использования технологий, которые используют виртуализацию. Во многих статьях есть поле манипуляций — это выводы на основе одного бенчмарка или когда надо доказать и обосновать, что принятое решение самое лучшее. В рамках статьи будет проверка работы clickhouse запускаемый в qemu‑kvm, firecracker, containerd.

Атаки на виртуальную инфраструктуру VMware ESXi в последнее время стали заметно набирать обороты. Сценарий, когда злоумышленник получает доступ к гипервизору, а затем останавливает все виртуальные машины и шифрует их диски, выглядит пугающе реалистично, особенно если компания не подготовлена к таким угрозам. Речь не только о редких случаяx, когда проникают особо изощрённые APT-группы. Всё чаще встречаются относительно простые, но крайне эффективные шифровальщики, которые атакуют хост ESXi, оставляя администраторов и владельцев инфраструктуры с зашифрованными файлами и практически без каких-либо зацепок для быстрого восстановления.

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

Мое внимание привлек тот факт, что ни одно средство защиты информации не воспринимало эти файлы как вредоносные.