Я собираю двухъядерный четырехъядерный (т.е. всего 8 ядер) Linux-сервер с 12 ГБ ОЗУ для замены нескольких старых меньших серверов. Я хотел бы использовать виртуализацию как для того, чтобы узнать об этом, так и потому, что людей, которые использовали старые серверы, нужно держать отдельно.
У меня будет два SSD-диска по 120 ГБ в зеркале RAID и 2 диска SATA II по 2 ТБ в зеркале RAID.
Я полагаю, что буду использовать Ubuntu 10.04 LTS с KVM в качестве хост-системы и Ubuntu 10.04 для основной ресурсоемкой гостевой виртуальной машины. Три дополнительных гостевых виртуальных машины, вероятно, будут Debian Lenny, они мало используются и имеют низкий приоритет.
Имеет ли смысл следующий план распределения ресурсов или более опытные пользователи видят подводные камни?
В частности, хватит ли 12 ГБ места для файлов хост-системы?
Будет ли достаточно свопа 12 ГБ? Использовать SSD в качестве места подкачки - плохая идея?
Основная гостевая виртуальная машина является наиболее часто используемым сервером, и ей требуется быстрый дисковый ввод-вывод, она часто перестраивает базу данных MySQL примерно 30 ГБ, требует много места для хранения файлов, запускает Apache и почтовый сервер. Вся покупка оборудования будет потрачена впустую, если этот сервер не работает должным образом.
Как мне разбить диски на разделы, чтобы проще всего сказать хост-системе, где разместить различные гостевые виртуальные машины? То есть я хочу, чтобы основная виртуальная машина использовала преимущества более быстрых SSD-дисков для своих файлов ядра / ОС и использовала диски SATA для своего хранилища, и хочу, чтобы менее важные виртуальные машины просто использовали часть дисков SATA и оставались выключенными. SSD.
Могу ли я выделить больше ОЗУ или ЦП для гостевых виртуальных машин (перегрузить), не вызывая проблем, или это того не стоит?
Спасибо за любые предложения.
«Похоже, вы планируете сконцентрировать несколько отдельных работающих серверных машин в одном массивном сервере с единственной точкой отказа». Я думаю, Вы ошибаетесь. KVM - очень хороший выбор для отказоустойчивого решения. Просто перенесите файл определения XML на другой сервер и используйте общее хранилище и / или идентичную конфигурацию сетевой карты для всех серверов в кластере. Проверял, работал. Помните про LACP и агрегацию ссылок - тоже работает :)
Моя установка в чем-то похожа и работает хорошо. Virt-manager делает это очень просто (даже при пересылке ssh X работает хорошо). Некоторые случайные мысли:
В этом сценарии я бы использовал LVM + virtio (возможно, за исключением очень больших томов; похоже, что с virtio возникла «проблема с 1 ТБ»). Вы можете поместить объем виртуальной машины с интенсивным вводом-выводом на самую быструю часть sata raid.
Своп: если вы точно не знаете, почему вам вообще не нужно 12 ГБ.
В небольших системах я бы рекомендовал отделить объем данных от системного тома. Вы, вероятно, будете использовать ~ 4 ГБ из 8 ГБ для системных файлов, оставив только 4 ГБ для тех моментов «упс». Системы работают намного лучше, когда их корневой том не заполнен.
Какой рейд вы используете? DM-softraid или какой-нибудь аппаратный контроллер с батарейным питанием?
Размещение системных файлов на SSD даст вам хорошее время загрузки, но не намного больше. Помещение файлов данных (особенно интенсивного поиска) на SSD будет доставлять вам огромное удовольствие в течение очень долгого времени.
Afaik все еще есть некоторый выигрыш, если вы не заполните свой 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 пакет потерян при отсоединении кабеля). Теперь мне интересно, возможно ли достичь 2 Гбит по сети до KVM VM ...
Следующее - настроить кластер.
Как системному администратору, ответственному за поддержание работы, этот план вызвал у меня неприятное чувство. Похоже, вы планируете сконцентрировать несколько отдельных работающих серверных машин в одном массивном сервере с единой точкой отказа. Любой простой этого суперсервера будет означать простой для ВСЕХ ваших сервисов, а не только для их части.
Я бы рекомендовал использовать ваш бюджет, чтобы вместо этого предоставить, скажем, два или три меньших сервера. Вы по-прежнему можете использовать виртуализацию для разделения ваших сервисов на отдельные контейнеры как для безопасности, так и для упрощения резервного копирования и миграции.
Мне не нравятся твои диски. Похоже на совершенно неправильный фокус.
У меня будет два SSD-диска по 120 ГБ в зеркале RAID и 2 диска SATA II по 2 ТБ в зеркале RAID.
Предполагая, что вы используете 120 ГБ для операционной системы и 32 ГБ для виртуальных машин - добро пожаловать в отсасывающий ввод-вывод. Хорошо, конечно, ваш сервер маленький.
Во всяком случае, вот некоторые из моих серверов:
10 ГБ Hyper-V на базе AMD (подходит для 16 ГБ, проблемы с BIOS были). Диски OS + находятся на RAID 10, Adaptec, 4x 320gb Black Scorptio. Загрузка ввода-вывода ПЛОХАЯ. Я чувствую, что он перегружен. Теперь он получает обновление до 16 ГБ, но количество виртуальных машин будет уменьшено - слишком большая нагрузка ввода-вывода во время установки исправлений и т. Д.
64 ГБ, 8-ядерные оптероны AMD. У меня был Velocirraptors 4x300 ГБ в RAID 10. Наполнялся, и я ЧУВСТВОВАЛ НАГРУЗКУ. Действительно чувствую это. Я только что обновился до 6 хищников в RAID 10 и могу подняться выше. На этом сервере было несколько серверов баз данных, но почти все они имеют отдельные диски для работы с базами данных. RAID-контроллер - это Adaptec 5805 в инфраструктуре SAS.
Как видите - ваша подсистема ввода-вывода действительно плохая. Избыточная память только сделает это НАМНОГО хуже. SSD может работать нормально, но все же слишком дорого. Если вы поместите виртуальные машины на диски емкостью 2 ТБ, ваш ввод-вывод будет просто отстой. У них, вероятно, около 250 операций ввода-вывода в секунду или около того каждый - по сравнению с 450, которые я измерил на своих хищниках, и, как я уже сказал, я использую их много, И они находятся на высококлассном рейд-контроллере.
У меня есть хорошая клетка SuperMicro с 24 слотами для дисков для более крупного сервера;)
Вот ваши доступные ресурсы:
В связи с вашим планом на ум приходит несколько мыслей:
Наслаждайтесь KVM! Не забудьте сделать резервную копию вашего Domain.XML и копии каждой виртуальной машины, желательно за пределами сайта.