Продолжая тему, описанную здесь habrahabr.ru/post/252973, опять пишу про увеличение дисков виртуальных машин.
Конфигурация следующая:
Гипервизор сервер Supermicro с KVM и libvirt на Ubuntu.
Гости — Ubuntu с LVM2.
Задача:
Увеличить размер системного дисков без выключения/перезагрузки гостевой ОС.

В комментариях к предыдущей статье habrahabr.ru/post/252973/#comment_8330673 farcaller написал:

Системный тоже можно на лету отресайзить. Для этого в libvirt есть команда:
virsh qemu-monitor-command resized-virtual-machine --hmp «block_resize $DRIVENAME $NEWSIZE»

Для HA проектов это очень важный момент, необходимо непрерывное функционирование сервиса.
Я решил попробовать изменить размер диска при помощи virsh.
Ниже результаты этого успешного эксперимента.

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

Архитектура, которую поощряет Docker — это изолированные контейнеры, каждый из которых выполняет одну команду. Эти контейнеры должны знать только как друг друга найти — другими словами, о контейнере нужно знать его fqdn и порт, или ip и порт, то есть, не более, чем о любой внешней службе.

Рекомендованный способ сообщить такие координаты внутрь процесса, выполняемого в Docker — переменные окружения. Типичный пример этого подхода, не применительно к докеру — DATABASE_URL, принятый во фреймворке Rails или NODE_ENV принятый в фрейворке Nodejs.

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

Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.

Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.

Жила-была у меня машина с XenServer 6.5 на борту и несколькими массивами из SATA-дисков. В последнее время перестало хватать быстродействия SATA и было решено заменить один массив на SAS-диски. Для этих целей был найден RAID-контроллер Adaptec 3805 (знаю, что старье, зато халява).

После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».

После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…

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

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

Как сделать слепок системы так, чтобы он запустился без проблем?

Интернет подсказывал несколько решений, вот только у меня исходная система windows server 2003, и даже с кряком не всё работает, нужен кряк под сервер. Скажу сразу, Акронис не подойдёт, Парагон диск менеджер серверный может сделать слепок системы, но выгружает его не на локальные диски, а только на физические диски. Имейте это ввиду, когда решите их использовать.

Интернет подсказал. В блоге Андрея Бешкова была ссылка на бесплатную утилиту disk2vhd. Маленькая, да удаленькая, позволяет сделать снимок работающей системы и выгрузить его на локальный диск.

Когда вы указываете в Dockerfile:

FROM ubuntu

то к вам на машину стягивается официально-поддерживаемый базовый образ Ubuntu (на сегодняшний день это 14.04 LTS). Мне стало интересно, чем образ этот отличается от «настоящей» чистой системы.

В процессе pull можно заметить, что он состоит из 5 слоёв:

docker pull ubuntu

ubuntu:latest: The image you are pulling has been verified
511136ea3c5a: Pull complete
3b363fd9d7da: Downloading 8.641 MB/197.2 MB 3m18s
607c5d1cca71: Download complete
f62feddc05dc: Download complete
8eaa4ff06b53: Download complete

Чтобы понять содержание каждого слоя, можно выполнить команду:

docker history --no-trunc ubuntu > history.txt

либо посмотреть исходный Dockerfile на GitHub. Каждый слой соответствует отдельной строке в Dockerfile:

511136ea3c5a — это отправная точка, пустой образ под названием scratch (строка FROM scratch).

3b363fd9d7da — «вливание» официального образа Ubuntu из файла ubuntu-trusty-core-cloudimg-amd64-root.tar.gz

Не так давно начал изучать, что такое docker, который уже успел нашуметь по всему миру. Не буду вдаваться в философские изыски «а зачем оно надо?», или «фи, это просто очередной модный тренд!», или «кто же такой сырой продукт выпускает?». Я просто хочу дать краткие советы, как можно быстро в домашних условиях пощупать, что такое docker, используя такие блага и удобства как SkyDock и SkyDNS.
Данная заметка рассчитана на людей, у кого мало времени, чтобы читать горы статьей на английском (или не знают английского), но есть небольшие познания в том, что такое консоль и как установить docker самостоятельно.

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

Это небольшой обзор способов запуска графических приложений в контейнерах Docker.

Предисловие

Был обычный вечер. Заняться было нечем, а скоротать время до сна каким-то образом надо было.
Решил я почистить свой внешний HDD от хлама, а заодно и проверить, есть ли новая прошивка на любимый карман Zalman VE-300. Зайдя на сайт Zalman, я как раз такую и обнаружил. Пока прошивка скачивалась через невероятно медленный EDGE, я просматривал changelog. Мой взор привлекла такая строчка:
Support VHD of MS / VMDK of VMWare which is virtual Hard disk file (Still not support for Dynamic)

Практика показывает, что любой процесс, в определенной степени, всегда можно оптимизировать. Это вполне можно отнести и к виртуализации. Возможностей оптимизации тут достаточно много, и задача эта многогогранна.

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

В пределах данной статьи я хочу познакомить вас с VMWare vSphere и рассмотреть базовые вопросы подбора её аппаратного и программного обеспечения.

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

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

Почему VMWare? Все просто, я являюсь специалистом по данной среде виртуализации, имею статус VCP5. Продолжительное время работал с крупными заказчиками и имел доступ к их системам.

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

На работе мы активно используем виртуализацию на базе qemu/kvm через libvirt. Сам я давно пересел на linux и также использую qemu/kvm на своей локальной машине, при этом, часто применяю графический virt-manager для настройки различных параметров ВМ. Хотелось использовать его и для управления гипервизорами на удаленных серверах. О том как это сделать и будет статья в виде пошаговой инструкции(по факту это перевод и «сведение в едино» официальной документации).

Давно хотел написать целостный туториал по поднятию Owncloud в условиях домашнего сервера или небольшой компании до 500 пользователей. Owncloud — это прекрасный open-source проект, который позволяет на собственной инфраструктуре поднять свой вариант сервера синхронизации. По возможностям очень похож на Dropbox, а в чем-то его и превосходит. Огромный плюс — отсутствие ограничений по объемам хранения, полный контроль над сервером. Минусы тоже очевидны: вам самим придется следить за всем этим безобразием и беспокоиться о надежности сервера, валяющегося на антресолях или в шкафу.

Совсем недавно мне подвернулась задача по развертыванию Owncloud в домашне-боевых условиях. Я честно отработал свои два литра кошерного русского имперского стаута и решил поделиться своим опытом, собрав все воедино. Итак, сегодня мы рассмотрим:

1. Развертывание актуального LEMP-stack
2. HTTPS. Let's Encrypt для Nginx с автоматическим обновлением сертификата
3. Конфигурирование Nginx для Owncloud
4. Кэширование php-apcu
5. Подключение внешнего основного хранилища по NFS

Все вы знаете систему Git. Хотя бы слышали — это наверняка. Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги. Система управления версиями Git де-факто является стандартом в индустрии. У разработчика могут быть мнения о преимуществах Mercurial, но чаще всего приходится мириться с требованием уметь пользоваться Git. Как у любой сложной системы, у нее множество полезных и необходимых функций. Однако, до гениальной простоты добираются не все, поэтому существующая реализация оставляла пространство для совершенствования.

Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может быть преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.

Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.

В этом эссе описана схема работы Git. Предполагается, что вы знакомы с Git достаточно, чтобы использовать его для контроля версий своих проектов.

Эссе концентрируется на структуре графа, на которой основан Git, и на том, как свойства этого графа определяют поведение Git. Изучая основы, вы строите своё представление на достоверной информации, а не на гипотезах, полученных из экспериментов с API. Правильная модель позволит вам лучше понять, что сделал Git, что он делает и что он собирается сделать.

Текст разбит на серии команд, работающих с единым проектом. Иногда встречаются наблюдения по поводу структуры данных графа, лежащего в основе Git. Наблюдения иллюстрируют свойство графа и поведение, основанное на нём.

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

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

(5:562)$ netstat -s |wc -l
124

Ура, у нас куча полезной информации, сейчас мы быстренько сообразим, что к чему. Вот только бы понять, что же это за зверь такой timeout in transit, явно что-то нехорошее.

В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.

Обычно это расширение используется администраторами баз данных в качестве источника данных для отчетов (эти данные на самом деле являются суммой показателей с момента сброса счетчиков). Но на основе этой статистики можно сделать мониторинг запросов — посмотреть на статистику во времени. Это оказывается крайне полезно для поиска причин различных проблем и в целом для понимания, что происходит на сервере БД.

Я расскажу, какие метрики по запросам собирает наш агент, как мы их группируем, визуализируем, так же расскажу о некоторых граблях, по которым мы прошли.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

PostgreSQL, как и любая другая СУБД, умеет делать некоторые проверки при вставке/изменении данных, и этим обязательно нужно уметь пользоваться. Давайте посмотрим, что мы можем проверять:

1. Кастомный подтип через ключевое слово DOMAIN

Разработчики вирусного ПО и просто разработчики, не желающие, чтобы их программу пытались реверсить, на этапе запуска или установки проводят проверки на виртуальную машину, и в случае её обнаружения отказываются работать, а то и вовсе самоликвидируются. Под катом описан способ, как можно попробовать решить эту проблему.