Планирование моего первого сервера с виртуальными машинами Ubuntu KVM
Я собираю двухъядерный четырёхъядерный (то есть всего 8 ядер) 12 ГБ ОЗУ сервер Linux для замены нескольких старых небольших серверов. Я хотел бы использовать виртуализацию, чтобы узнать об этом и потому, что люди, которые использовали старые серверы, должны быть разделены.
У меня будет два накопителя на 120 ГБ в зеркале RAID и 2 диска SATA II емкостью 2 ТБ в зеркале RAID.
Я полагаю, что буду использовать Ubuntu 10.04 LTS с KVM в качестве хост-системы и Ubuntu 10.04 для основной ресурсоемкой гостевой виртуальной машины. Вероятно, тремя дополнительными гостевыми виртуальными машинами будут Debian Lenny, они мало используются и имеют низкий приоритет.
Имеет ли смысл следующий план распределения ресурсов или более опытные пользователи видят подводные камни?
- Хост-система: используйте 24 ГБ от SSD, то есть 12 ГБ для файлов + 12 ГБ в качестве подкачки
- Основная гостевая виртуальная машина: используйте 96 ГБ SSD + 1900 ГБ SATA (выделите 4 ЦПУ + 8 ГБ ОЗУ)
- DNS-сервер виртуальной машины: используйте 8 ГБ SATA (выделите 1 ЦПУ + 1 ГБ ОЗУ)
- VM WebServer: используйте 8 ГБ SATA (выделите 1 ЦПУ + 1 ГБ ОЗУ)
- VM Mail Server: используйте 8 ГБ SATA (выделите 1 ЦПУ + 1 ГБ ОЗУ)
- Зарезервировано для будущего использования: 76 ГБ SATA
В частности, будет ли 12 ГБ достаточно места для файлов хост-системы?
Будет ли достаточно 12 ГБ подкачки? Это плохая идея использовать SSD для пространства подкачки?
Основная гостевая виртуальная машина является наиболее часто используемым сервером, и ей требуется быстрый дисковый ввод-вывод, она часто перестраивает примерно 30 ГБ базы данных MySQL, требует много места для хранения файлов, запускает Apache и почтовый сервер. Вся эта покупка оборудования теряется, если этот сервер работает плохо.
Как я должен разбить диски, чтобы легче было указать хост-системе, куда поместить различные гостевые виртуальные машины? То есть я хочу, чтобы основная виртуальная машина использовала преимущества более быстрых дисков SSD для своих файлов ядра / ОС, использовала диски SATA для своего хранилища и хотела бы, чтобы менее важные виртуальные машины просто использовали часть дисков SATA и оставались отключенными. твердотельные накопители.
Могу ли я выделить больше ОЗУ или ЦП для гостевых виртуальных машин (overcommit), не вызывая проблем, или это просто не стоит?
Спасибо за любые предложения.
7 ответов
"Похоже, вы планируете сконцентрировать несколько отдельных работающих серверных компьютеров в один массивный сервер с одной точкой отказа". Я думаю, что вы не правы. KVM - очень хороший выбор для решения проблем при отказе. Просто перенесите файл определения XML на другой сервер и используйте общее хранилище и / или идентичную конфигурацию сетевой карты для всех серверов в кластере. Проверено, сработало. Помните про LACP и агрегацию ссылок - тоже работает:)
Моя установка несколько похожа и работает хорошо. Virt-manager делает это действительно легко (даже при пересылке по ssh X это работает хорошо). Несколько случайных мыслей:
В этом сценарии я бы использовал LVM + virtio (возможно, за исключением очень больших томов; кажется, что с virtio возникла проблема в 1 ТБ). Вы можете поместить том vm с интенсивным вводом-выводом в самую быструю часть sata raid.
Поменяйте местами: если вы точно не знаете, почему вам вообще не нужно 12 ГБ.
В небольших системах я бы порекомендовал отделить объем данных от системного. Вы, вероятно, будете использовать ~4 из 8 ГБ для системных файлов, оставляя только 4 ГБ для этих "упс" моментов. Системы ведут себя намного лучше, когда их корневой том не заполнен.
Какой рейд вы используете? DM-softraid или какой-то аппаратный контроллер с батарейным питанием?
Размещение системных файлов на SSD даст вам хорошее время загрузки, но не намного после этого. Размещение файлов данных (особенно интенсивного поиска) на SSD доставит вам огромное удовольствие в течение очень долгого времени.
Афаик, все еще есть некоторая выгода, если вы не заполните свой SSD полностью, оставив 20% неиспользованными (никогда не записанными) легко с LVM, просто сделайте объем для этого.
Как и при любой перестройке оборудования, я настоятельно рекомендую использовать память ECC.
12 ГБ должно быть достаточно для вашей системы.
12 ГБ должно быть более чем достаточно для подкачки. Я бы не стал сильно беспокоиться о скорости доступа к свопу, так как своп обычно мало используется. С вашей доступной памятью вы не должны видеть никаких значительных перестановок. Если вам нужно большое временное пространство, вы можете использовать больший размер подкачки и использовать tmpfs для / tmp.
Вы можете вручную разместить файловые системы виртуальных систем в виде файлов или разделов. Они будут там, где вы их разместили.
У вас гораздо больше ОЗУ и ЦП, чем кажется необходимым. Следите за использованием памяти на серверах и увеличивайте по мере необходимости.
Я бы установил на сервере процесс munin, а на сервере и всех виртуальных серверах - клиенты munin. Это позволит вам быстро определить, есть ли у вас какие-либо узкие места, которые необходимо устранить.
Я бы не стал перегружать ОЗУ, но в зависимости от нагрузки вы сможете перегружать процессоры. Учитывая вашу увеличенную силу, это не должно быть необходимым. KVM позволяет вам указать максимальные значения для обоих из них, которые выше, чем используемые при запуске. Я не пытался динамически изменять эти значения.
Все это звучит как тестовый сервер, который у нас уже есть:)
Что ж, избегайте OCZ Vertex SSD, даже если они могут выполнять чтение 550 МБ / с и запись 530 МБ / с - они, вероятно, слишком неисправны, вы можете прочитать это в сети. Но я не проверял их сам.
Для меня лучшим вариантом по-прежнему остаются диски SAS или FC в массиве RAID10, даже если SSD будет выполнять больше операций ввода-вывода, но его срок службы ограничен (получите от SMART эти данные!). Когда диск выходит из строя, вы просто заменяете его, что произойдет, когда все SSD будут одной серии и все выйдут из строя сразу? Э-э.
Да, я могу подтвердить, что память для ВМ очень интенсивна. Однажды я включил экран, и Ubuntu Server говорил, что очередь ввода-вывода слишком велика или что-то в этом роде, и она зависла надолго.
Я выделяю столько ЦП / ОЗУ, сколько мне нужно для виртуальных машин, например, если требуется развернуть новую ВМ, я сокращаю ОЗУ для остальной части во время обслуживания, не слишком много, но достаточно для новой ВМ.
Сейчас я тестирую соединение вместе с мостом именно для виртуальных машин KVM. Я успешно установил режим соединения LACP и циклический перебор (тест показывает, что 1 пакет потерян, когда кабель отключен). Теперь мне интересно, возможно ли достичь 2Gbit по сети до KVM VM...
Следующая вещь, чтобы настроить кластер.
Вот ваши доступные ресурсы:
- 8 ядер
- 12 ГБ ОЗУ
- 120GB SSD-накопитель
- 2 ТБ для хранения данных
Несколько мыслей приходят на ум с вашим планом:
- Прежде всего, 12 ГБ ОЗУ?... Потратить больше $ и получить больше ОЗУ!
- Я хотел бы рассмотреть запуск "Хост-системы" с отдельного небольшого SSD (скажем, 32 ГБ) или дисков SATA, предполагая, что все, что делает хост - это запускает KVM. Моя главная причина этого заключается в том, что я бы хотел напрямую передать весь 120 ГБ SSD непосредственно на вашу рабочую виртуальную машину.
- Я также использую "CPU Pinning" для моей основной виртуальной машины (закрепите весь процессор, так как у вас их два!)
- Я также использую ОЗУ "HugePages", которое в основном резервирует ОЗУ только для этой ВМ, например, для закрепления ЦП, но для ОЗУ.
- Я хотел бы дать каждой виртуальной машине по крайней мере 1 ядро с 2 потоками для малых виртуальных машин и 4 ГБ оперативной памяти.
- Своп не нужен, если вы часто используете своп, ваша система недостаточно мощная. Это как последнее средство, а оперативная память достаточно дешевая, теперь она не нужна
- Было бы неплохо предоставить "Хост-системе" небольшой объем памяти, если у нее есть доступ к дискам Sata емкостью 2 ТБ для резервного копирования и т. Д.
- Чрезмерное использование ресурсов - это путь IMO, поскольку гипервизор может выделять его по мере необходимости, но если вы часто сталкиваетесь с узкими местами, вы можете подумать об ужесточении своих ресурсов, чтобы приоритетные процессы работали более плавно.
- Наконец, я понимаю, что вы и ваша работа, вероятно, больше знакомы с ОС на основе Debian, но не так сложно перейти на другой дистрибутив Linux, если вы понимаете Linux. Вы просто меняете 'apt-get' на 'yum' или 'dnf', и несколько файлов расположены в разных местах, но Google поможет вам. Моя главная причина сказать, что я всегда хочу использовать дистрибутив на основе RHEL для запуска KVM, так как RHEL разрабатывает KVM. Я лично использую FEDORA. KVM - это новая IMO, и я нашел причины / улучшения, которые были только у Fedora, когда другие ОС все еще работали над импортом.
- 8 ГБ памяти для ОС Linux действительно мало. Я хотел бы 32 ГБ. Хранение Сата дешево. Лучшая цена на данный момент - это диски емкостью 8 ТБ, но это может быть излишним, несмотря на то, что 8 ГБ невелики.
- Найдите какое-то решение для мониторинга, которое может предупредить вас о таких проблемах, как узкие места в ОЗУ / ЦП / Хранилище. Мне нравится XYMon, но я тоже заглянул в Zabbix.
Наслаждайтесь KVM! Обязательно сделайте резервную копию вашего Domain.XML и копии каждой виртуальной машины вне сайта.
Как системный администратор, ответственный за поддержание работоспособности, этот план доставит мне неприятные ощущения. Похоже, вы планируете сконцентрировать несколько отдельных работающих серверных машин в один массивный сервер с одной точкой отказа. Любое время простоя этого суперсервера будет означать время простоя ВСЕХ ваших сервисов, а не только их подмножество.
Я бы рекомендовал использовать ваш бюджет для обеспечения, скажем, двух или трех небольших серверов. Вы все еще можете использовать виртуализацию для разделения ваших служб на отдельные контейнеры, как для обеспечения безопасности, так и для упрощения резервного копирования и миграции.
Мне не нравятся твои диски. Похоже, совершенно неправильный фокус.
У меня будет два накопителя на 120 ГБ в зеркале RAID и 2 диска SATA II емкостью 2 ТБ в зеркале RAID.
Предполагая, что вы используете 120 ГБ для операционной системы и 32 ТБ для виртуальных машин - добро пожаловать в отсос IO. Хорошо, конечно, ваш сервер маленький.
Во всяком случае, вот некоторые из моих серверов:
Hyper-V на базе AMD 10 ГБ (умещается на 16 ГБ, у нас были проблемы с BIOS). Диски OS+ находятся на RAID 10, Adaptec, 4x 320 ГБ Black Scorptio. IO нагрузка ПЛОХА. Я чувствую, что это перегружено. Теперь он обновляется до 16 Гб, но количество виртуальных машин будет уменьшено - слишком большая нагрузка ввода-вывода во время исправления и т. Д.
64 ГБ, 8 ядерных процессоров AMD. У меня был 4x300gb Velocirraptors в RAID 10 на нем. Наполнялся, и я чувствовал груз. Действительно чувствую это. Я только что обновил до 6 Raptor в RAID 10 и может пойти выше. На этом сервере было несколько серверов базы данных, но почти все они имеют отдельные диски для работы с БД. RAID-контроллер представляет собой Adaptec 5805 в инфраструктуре SAS.
Как видите, ваша подсистема ввода-вывода действительно плохая. Перегрузка памяти только сделает это намного хуже. SSD может работать хорошо, но все еще слишком дорого. Если вы поместите виртуальные машины на диски емкостью 2 ТБ, ваш IO будет просто отстой. Скорее всего, у них около 250 IOPS или около того - по сравнению с 450, которые я измерил на своих хищниках, и, как я уже сказал, я использую их много И они работают на высококлассном контроллере рейдов.
У меня есть хорошая клетка SuperMicro с 24 слотами для дисков для большого сервера;)