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

Всем привет! С вами снова Иван Протченко — инженер из команды Cloud.ru. Как вы знаете, cloud native образы помогают обеспечить предсказуемость, масштабируемость и отзывчивость приложений в облаке. В этой статье я по шагам покажу процесс подготовки таких образов с помощью Packer и QEMU в сочетании с мощным CI/CD-решением — GitLab CI.

Почему именно эти инструменты? Packer от HashiCorp поможет автоматизировать процесс создания конфигурируемых и воспроизводимых образов, QEMU обеспечит гибкость и производительность за счет эмуляции и виртуализации, а интеграция с GitLab CI позволит настроить надежный и повторяющийся пайплайн, который в разы упростит процесс сборки образов. Welcome!

В данной статье описывается пошаговая методика развертывания виртуальной машины (ВМ) с установленной операционной системой Windows 10 на сервере с операционной системой Ubuntu. Решение предполагает установку всех необходимых компонентов, настройку виртуализации с помощью QEMU/KVM, а также организацию удалённого доступа к ВМ посредством noVNC.

Работать с YADRO мы начали еще несколько лет назад, главной задачей нашего сотрудничества было и остается обеспечение совместимости между СХД TATLIN и нашей платформой управления динамической инфраструктурой Basis Dynamix Enterprise. Наша платформа и раньше умела работать с различными СХД — Hitachi, Huawei и других. Однако где-то были реализованы не все возможности, где-то не хватало веб-интерфейса и приходилось работать через консоль, где-то страдало быстродействие. Тесное сотрудничество с YADRO позволяло подходить к решению этих проблем с обеих сторон, плюс, многие наши заказчики регулярно интересовались развитием поддержки TATLIN.UNIFIED в наших продуктах. И вот на этой неделе мы объявили о более глубокой интеграции между TATLIN.UNIFIED Gen 2 и Basis Dynamix Enterprise, включающей поддержку репликации и мгновенных снимков через интерфейс платформы. О чем и хотим рассказать подробнее.

Хабр, привет! Меня зовут Игорь Сомов, я работаю инженером по внедрению в компании «Базис». До этого почти 20 лет работал в ИТ — начинал монтажником, был эникеем на заводах, системным администратором в разных компаниях. Даже уходил из ИТ на какое-то время, но в итоге вернулся в профессию. В «Базис» пришел пару лет назад, в создающуюся команду внедрения, вместе с которой делал первые шаги в автоматизации разворачивания платформы Basis Dynamix. Сейчас выбранный нами подход выглядит немного наивным, но тогда это был существенный результат, который позволил нам создать базу для дальнейшей работы. О том, как это было, я и хочу рассказать.

Представьте мир, где каждый персонаж живёт своей жизнью: принимает решения, взаимодействует с окружающей средой и даже эволюционирует. Где почва, растения и ресурсы подчиняются сложным алгоритмам, а нейронные сети управляют поведением тысяч существ. Это не сценарий для нового блокбастера — это проект, над которым я работаю.

В этой статье я расскажу, как с помощью NestJS, TypeORM и Tensorflow.js создаю виртуальную вселенную, которая “дышит” и развивается. Мы разберём:

Современная бэкенд‑разработка не обходится без средств контейнеризации. Самому простому приложению, скорее всего, будет нужна хотя бы база данных или пучок дополнительных зависимостей из веб‑серверов, балансировщиков, сборщиков логов и метрик. Для быстрого их развёртывания и настройки используются кастомные или готовые образы и контейнеры. И когда разговор заходит о контейнерах, первое, что приходит на ум, — это 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, которая в последнее время становится всё более популярной для сетевых дисковых подключений. Мы сейчас строим некую новую систему и у меня возникла мысль протестировать и сравнить несколько различных настроек. Возможно, кому-то из коллег будут полезны полученные мной результаты.