Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
VPS около 100 сайтов
и ни слова о raid…
я не такой бесстрашный
Статья про установку Linux? Дак вроде не одна тысяча их. Да и про настройку ProxMox тоже предостаточно. Убедить купить IP ну это конечно да. Даже не знаю про что статья в общем.
Что надо отметить: на ssd установлен proxmox
Т.е. когда SSD сдохнет, вы получите автоматом проблемы с загрузкой системы, равно как и с её восстановлением.
Заливаем в машину образ CentOS. Тут было некое неудобство от ProxMox — можно качнуть образ не по ссылке, а только имеющийся у себя на харде. Так что пришлось сначала лить к себе, потом выливать на сервер.
Достаточно было зайти по ssh на машину с proxmox и скачать wget'ом образ в /var/lib/vz/template/iso/
С WD (/dev/sdb)
Так сколько у вас дисков, 1 или 2? Если один, то, опять же, взашей гнать всех, кто участвовал в разработке конфигурации, закупке, а затем согласился ставить систему на заведомо рискованную конфигурацию. Если два, то где второй? Почему не используется raid, если у вас 100 сайтов?
ОЗУ 4 Гб; процессор «по умолчанию kvm64», СД — привод образ CentOS, HDD — образ диска от vmvare (vmbr), кэширование write back, 120 Gb на хранилище ws, сетевая Intel на бридже vmbr0.
kvm64 для проца для одиночной установки? Зачем, у вас есть лишние ресурсы? Для гомогенных кластеров и односерверных установок для виртуальных машин нужно использовать тип cpu 'host'.
Для каких целей вы используете формат vmdk (а не vmbr, как статье)? Почему не родные qcow2 или raw? Тип жесткого диска вы тоже не указали, но подозреваю, что используется ide?
В наше время для почти всех OS нужно использовать virtio (то же самое касается и сети). Это значительно снижает нагрузку на хост и увеличивает производительность соответствующих подсистем VM.
Кстати, вот к этому:
Так как я потратил на установку образа ОС час, то я решил оптимизировать этот процесс для следующих n-машин. Поэтому в консоли зашел /var/lib/ws/images/100, и скопировал образ диска vmbr в папку /home
Если бы использовали формат диска qcow2, могли бы использовать так называемые thin-provisioned диски, т.е. у вас был бы один образ в качестве основного, а изменения конкретных виртуалок накапливались бы в отдельных контейнерах.
В общем, так практически по всей статье. Даже новичкам это читать просто вредно.
Для каких целей вы используете формат vmdk (а не vmbr, как статье)? Почему не родные qcow2 или raw? Тип жесткого диска вы тоже не указали, но подозреваю, что используется ide?
Использую SCSI. Формат выбран для совместимости с другими машинами виртуализации. VMVare взял за стандарт де-факто.
Т.е. когда SSD сдохнет, вы получите автоматом проблемы с загрузкой системы, равно как и с её восстановлением.
Просьбу заказчика требуется выполнять. SSD позволит взлететь систему даже когда сдохнет.
Так сколько у вас дисков, 1 или 2? Если один, то, опять же, взашей гнать всех, кто участвовал в разработке конфигурации, закупке, а затем согласился ставить систему на заведомо рискованную конфигурацию. Если два, то где второй? Почему не используется raid, если у вас 100 сайтов?
Вверху привел конфигурацию сервера: два харда — SSD и WD. Работаю с чем дали.
У вас там написано: 2 WD… — неясно из контекста, это 2 шт. или порядковый номер два.
Я бы вам всё-таки рекомендовал использовать virtio и нативный формат контейнера. вы выбрали самый медленный вариант из возможных.
Кроме того — я не написал это выше — выход из строя ssd, на котором вы расположили swap-файлы виртуалок, обрушит и виртуалки тоже. Хотя, если в системе в принципе нет двух одинаковых дисков, это не имеет значения.
Если вы этого не сделали, я бы рекомендовал вам уведомить заказчика о том, что вы снимаете с себя ответственность за сохранность данных и системы в целом в таких условиях.
Я бы вам всё-таки рекомендовал использовать virtio и нативный формат контейнера. вы выбрали самый медленный вариант из возможных.
Кроме того — я не написал это выше — выход из строя ssd, на котором вы расположили swap-файлы виртуалок, обрушит и виртуалки тоже. Хотя, если в системе в принципе нет двух одинаковых дисков, это не имеет значения.
Если вы этого не сделали, я бы рекомендовал вам уведомить заказчика о том, что вы снимаете с себя ответственность за сохранность данных и системы в целом в таких условиях.
Если вы этого не сделали, я бы рекомендовал вам уведомить заказчика о том, что вы снимаете с себя ответственность за сохранность данных и системы в целом в таких условиях.
Сделано заранее.
Я себе слабо представляю обрушение виртуалки из-за отсутствия swap-диска.
Кстати, да, решение может быть в следующем: CentOS (как и прочие nix) поддерживает swap-диски и swap-файлы. Можно организовать дополнительно одновременно со swap-диском на ssd swap-файл на основном диске, который позволит системе не рухнуть.
Ради интереса решил посмотреть использование swap на сервере: 1% на apache, на остальных не используется. Uptime 14 дней.
Кстати, да, решение может быть в следующем: CentOS (как и прочие nix) поддерживает swap-диски и swap-файлы. Можно организовать дополнительно одновременно со swap-диском на ssd swap-файл на основном диске, который позволит системе не рухнуть.
Ради интереса решил посмотреть использование swap на сервере: 1% на apache, на остальных не используется. Uptime 14 дней.
Если у вас что-то есть в свапе и он отвалится, в лучшем случае у вас вылетит приложение (конкретный сервис, исполняемый поток, не знаю, как его назвать лучше), чей код\данные были выгружены в свап. Если он пуст — возможны варианты, но вероятность паники минимальна, конечно. Опять же, ровно до момента попытки записи в свап, что будет дальше — вопрос.
«Если бы использовали формат диска qcow2, могли бы использовать так называемые thin-provisioned диски, т.е. у вас был бы один образ в качестве основного, а изменения конкретных виртуалок накапливались бы в отдельных контейнерах.»
qcow2 выглядит очень привлекательно, но только на первый взгляд. Его единственное отличие от vmdk — live-снапшоты, но на практике они оказываются не очень нужны. Бэкапы можно делать через снапшоты lvm — как и делается.
thin-provisioned — это как раз не qcow2, а vmdk. thin-provisioned это вообше не то что, похоже, Вы думаете. qcow2 эмулирует thin с помощью разреженных файлов, но это само по себе приводит к некоторым проблемам — например, Вы не можете скопировать такой файл на устройство, не поддерживающее разреженные файлы, при бэкапировании скорость заметно ниже чем vmdk, и всегда остаётся опасность получить гигантский файл. При этом преимущества непонятны.
«один образ в качестве основного» — это что? Разве Proxmox это поддерживает? «Изменения конкретных виртуалок» — а кто считал сколько это экономит в процентах? 1% через месяц эсплуатации? И это ценой невозможности бэкапить виртуалки простым копированием и замедление всех операций? Такие оптимизации можно делать на огромной куче виртуалок, но не на 2-3.
Так что не только статья вредная, но и некоторые комментарии. Но беда в том, что по виртуализации вообще толковых статей на русском очень мало. Даже форум и wiki proxmox запутаны и малопонятны, так что любая статья и любое обсуждение — благо.
В общем, я ни разу не встречал обоснованной рекомендации использовать qcow2 вместо vmdk.
qcow2 выглядит очень привлекательно, но только на первый взгляд. Его единственное отличие от vmdk — live-снапшоты, но на практике они оказываются не очень нужны. Бэкапы можно делать через снапшоты lvm — как и делается.
thin-provisioned — это как раз не qcow2, а vmdk. thin-provisioned это вообше не то что, похоже, Вы думаете. qcow2 эмулирует thin с помощью разреженных файлов, но это само по себе приводит к некоторым проблемам — например, Вы не можете скопировать такой файл на устройство, не поддерживающее разреженные файлы, при бэкапировании скорость заметно ниже чем vmdk, и всегда остаётся опасность получить гигантский файл. При этом преимущества непонятны.
«один образ в качестве основного» — это что? Разве Proxmox это поддерживает? «Изменения конкретных виртуалок» — а кто считал сколько это экономит в процентах? 1% через месяц эсплуатации? И это ценой невозможности бэкапить виртуалки простым копированием и замедление всех операций? Такие оптимизации можно делать на огромной куче виртуалок, но не на 2-3.
Так что не только статья вредная, но и некоторые комментарии. Но беда в том, что по виртуализации вообще толковых статей на русском очень мало. Даже форум и wiki proxmox запутаны и малопонятны, так что любая статья и любое обсуждение — благо.
В общем, я ни разу не встречал обоснованной рекомендации использовать qcow2 вместо vmdk.
По Вашему мнению (как человека, который разбирается в предмете) в чем вред статьи?
Я не предлагал использовать qcow2 backing files concept в качестве рабочего решения, я упомянул, что такая возможность есть. Qcow2 — формат по умолчанию в Proxmox неспроста. Но вообще, я всегда рекомендую использовать raw с нормальным выделенным хранилищем (кластером системы хранения, если хотите). На последнем проекте выделенного хранилища не было, поэтому появился локальный zfs с набором ssd под ZIL и L2ARC, где backup решается на уровне резервного копирования live snapshot'ов FS. Причем решается неполноценно, потому что одна из виртуалок — Windows Server с контроллером реплицируемого домена, который срезервировать копированием невозможно — он не восстановится потом. Так что и возможность backup копированием файлов VM — не панацея.
А то, что proxmox что-то не поддерживает, так proxmox (в случае односерверной установки) не более чем GUI для стандартных инструментов.
И основные отличия vmdk от qcow2 (и, тем более, от raw и lvm-raw) — в скорости. Это главное.
А то, что proxmox что-то не поддерживает, так proxmox (в случае односерверной установки) не более чем GUI для стандартных инструментов.
И основные отличия vmdk от qcow2 (и, тем более, от raw и lvm-raw) — в скорости. Это главное.
Статья не про сферических коней, а про proxmox, так что любые возможности qcow можно упоминать только если их можно использовать в proxmox. Иначе обсуждение просто неконструктивно.
Proxmox ни в какой установке не «GUI для стандартных инструментов», так как никаких стандартных инструментов не использует.
И насчёт скорости. Приведите достоверные результаты тестирования скорости vmdk и qcow2 — тогда можно продолжать обсуждение их достоинства с точки зрения производительности.
Тут же отвечу насчёт «Даже десктоп SSD сейчас имеют настолько большое количество циклов перезаписи, что к тому моменту, как они закончатся диск скорее устареет морально.» Количество циклов перезаписи не увеличилось, изменились алгоритмы более равномерного использования SSD диска. Записываемый объём данных вполне предсказуем, для OCZ он вообще в последних моделях включался в гарантию. Для Kingston есть табличка:
www.kingston.com/datasheets/SV300S3_ru.pdf
Суммарное число записываемых байтов (TBW)
60ГБ: 32ТБ
120ГБ: 64ТБ
240ГБ: 128ТБ
480ГБ: 256ТБ
Суммарное число записываемых байтов (TBW) – это общий объем данных, который может быть записан на
твердотельный накопитель при указанной нагрузке до того, как накопитель достигнет предела износа.
Как видите, для сервера вполне достижимые цифры. На серверных моделях SSD они выше, но тоже не бесконечны.
В общем, статья не то чтобы вредная, но стоит помнить, что она просто описывает конкретный опыт, а не является руководством.
Proxmox ни в какой установке не «GUI для стандартных инструментов», так как никаких стандартных инструментов не использует.
И насчёт скорости. Приведите достоверные результаты тестирования скорости vmdk и qcow2 — тогда можно продолжать обсуждение их достоинства с точки зрения производительности.
Тут же отвечу насчёт «Даже десктоп SSD сейчас имеют настолько большое количество циклов перезаписи, что к тому моменту, как они закончатся диск скорее устареет морально.» Количество циклов перезаписи не увеличилось, изменились алгоритмы более равномерного использования SSD диска. Записываемый объём данных вполне предсказуем, для OCZ он вообще в последних моделях включался в гарантию. Для Kingston есть табличка:
www.kingston.com/datasheets/SV300S3_ru.pdf
Суммарное число записываемых байтов (TBW)
60ГБ: 32ТБ
120ГБ: 64ТБ
240ГБ: 128ТБ
480ГБ: 256ТБ
Суммарное число записываемых байтов (TBW) – это общий объем данных, который может быть записан на
твердотельный накопитель при указанной нагрузке до того, как накопитель достигнет предела износа.
Как видите, для сервера вполне достижимые цифры. На серверных моделях SSD они выше, но тоже не бесконечны.
В общем, статья не то чтобы вредная, но стоит помнить, что она просто описывает конкретный опыт, а не является руководством.
Proxmox ни в какой установке не «GUI для стандартных инструментов», так как никаких стандартных инструментов не использует.
Продолжаю считать, что Proxmox — это не более, чем web-ui для KVM\OpenVZ. Для работы она использует стандартные cli-утилиты названных выше инструментов. Не согласны? Аргументируйте, пожалуйста.
Например, Proxmox имеет API, контроль за выполнением задач, копирование конфигурации, отказоустойчивость, проверенные методики решения практических задач, поддержка бэкапирования, описание того что и как нужно делать для достижения результата и чего делать не надо, некоторые «стандартные утилиты» самими proxmox'овцами и поддерживаются. Для Proxmox даже web не нужен.
Как я понимаю, остальные мои возражения я писал для воздуа — Вы их не читали?
Как я понимаю, остальные мои возражения я писал для воздуа — Вы их не читали?
Я не понимаю, как то, что вы описали, противоречит тому, что сказал я. Это замечательно, что кто-то предложил «проверенные» методики (многие из которых, кстати, «проверяются» и создаются их же пользователями) и написал несколько скриптов, я с удовольствием пользуюсь их решением, но это — не более, чем Web GUI с — если вам так хочется — несколькими дополнительными скриптами. То, что вы перечислили, либо можно реализовать собственными скриптами за пару часов работы максимум, либо не актуально для (вы, видимо, пропустили мою пометку) односерверной установки. Более того, некоторые операции жестко зашиты в скрипты и нормального пути, для, скажем, монтирования nfsv4 и при этом сохранения возможности обновления просто нет.
Насчет «остального»: я увидел написанное вами. Только и тут не понимаю, как это противоречит моей мысли о том, что надежность SSD в наше время вполне себе позволяет использовать их и в серверном применении. Собственно, рискну предположить, что основная разница между серверным и несерверным SSD чаще всего в наличии у серверных SSD конденсаторов да больших объемов служебных областей для равномерного распределения нагрузки.
Насчет «остального»: я увидел написанное вами. Только и тут не понимаю, как это противоречит моей мысли о том, что надежность SSD в наше время вполне себе позволяет использовать их и в серверном применении. Собственно, рискну предположить, что основная разница между серверным и несерверным SSD чаще всего в наличии у серверных SSD конденсаторов да больших объемов служебных областей для равномерного распределения нагрузки.
Статья о ХП на картинке Делл. Ай ай ай :)
Пост написан как технический дневник: что увидел, то и записал. Сложно воспринимается.
Где логика и красота? Мысли разбегаются.
«Даже новичкам это читать просто вредно» — верное замечание.
Где логика и красота? Мысли разбегаются.
«Даже новичкам это читать просто вредно» — верное замечание.
>А вот swap файлы было решено размещать на ssd.
У SSD ограничено число циклов записи, не надо так делать.
>1. pvcreate /dev/sdb
>2. vgcreate ws /dev/sdb
>3. lvcreate -n data -L980G ws (размер 980 не помню как вычислил, по моему понижал от Террабайта по 10 гигов)
LVM создают вместо обычного тома тогда, когда хотят получить снэпшоты, а для них надо оставить место на томе, так что:
lvcreate -n data -L900G ws
а когда нам нужно сделать бэкап, то
lvcreate -s -n data-backup -L 50G /dev/ws/data
dd if=/dev/ws/data-backup of=/mnt/nfs/backup-server/mybackup.img
и т.п.
Кстати, в масонских ложах шепчутся, что поддержка vmdk сделана в QEMU для галочки и сливает по производительности QCOW2, а QCOW2 сливает RAW, потому что вынужден делать copy-on-write.
Отдельные еретики даже смеют утверждать, что наиболее правлславно использовать разделы lvm вместо образов дисков, т.к. это работает в обход VFS хоста, которая бьет длинные IO-запросы на кучу мелки по 4кб рамером
У SSD ограничено число циклов записи, не надо так делать.
>1. pvcreate /dev/sdb
>2. vgcreate ws /dev/sdb
>3. lvcreate -n data -L980G ws (размер 980 не помню как вычислил, по моему понижал от Террабайта по 10 гигов)
LVM создают вместо обычного тома тогда, когда хотят получить снэпшоты, а для них надо оставить место на томе, так что:
lvcreate -n data -L900G ws
а когда нам нужно сделать бэкап, то
lvcreate -s -n data-backup -L 50G /dev/ws/data
dd if=/dev/ws/data-backup of=/mnt/nfs/backup-server/mybackup.img
и т.п.
Кстати, в масонских ложах шепчутся, что поддержка vmdk сделана в QEMU для галочки и сливает по производительности QCOW2, а QCOW2 сливает RAW, потому что вынужден делать copy-on-write.
Отдельные еретики даже смеют утверждать, что наиболее правлславно использовать разделы lvm вместо образов дисков, т.к. это работает в обход VFS хоста, которая бьет длинные IO-запросы на кучу мелки по 4кб рамером
У клиента два сервера терминальных внутри ProxMox на Windows 2003 Serv для 1С крутится. Один на vmdk, другой на qcow2. Вот разницы в производительности по IO не заметил совершенно. Собственный опыт.
Не буду возражать, что возможно родной формат лучше, есть некоторые плюшки.
Не буду возражать, что возможно родной формат лучше, есть некоторые плюшки.
Не соглашусь с вами только касательно использования SSD, это миф из далёкого прошлого. Даже десктоп SSD сейчас имеют настолько большое количество циклов перезаписи, что к тому моменту, как они закончатся диск скорее устареет морально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание хостинга сайтов на базе Proxmox + HP ProLiant