Не получается создать raid5, загадочно разваливается ... :(

[sasha181]

Имеем OS Centos 5.5
3 диска по 2 террабайта WD

Таблицы разделов

/dev/sda1 * 1 1305 10482381 fd Автоопределение Linux raid
/dev/sda2 1306 5196 31254457+ fd Автоопределение Linux raid
/dev/sda3 5197 17355 97667167+ fd Автоопределение Linux raid
/dev/sda4 17356 243201 1814107995 fd Автоопределение Linux raid


/dev/sdb1 * 1 1305 10482381 fd Автоопределение Linux raid
/dev/sdb2 1306 5196 31254457+ fd Автоопределение Linux raid
/dev/sdb3 5197 17355 97667167+ fd Автоопределение Linux raid
/dev/sdb4 17356 243201 1814107995 fd Автоопределение Linux raid


/dev/sdc1 * 1 1305 10482381 fd Автоопределение Linux raid
/dev/sdc2 1306 5196 31254457+ fd Автоопределение Linux raid
/dev/sdc3 5197 17355 97667167+ fd Автоопределение Linux raid
/dev/sdc4 17356 243201 1814107995 fd Автоопределение Linux raid

Первые три раздела на дисках корень swap и раздел под БД
все в RAID-1 (создались без проблем)

четвёртый хочу сделать RAID-5 и отвести под OpenVZ виртуалки

Создаю так

Код: Выделить всё

mdadm --create /dev/md3 --level=5 --raid-devices=3 /dev/sd[abc]4

сразу после создания картина такова

Код: Выделить всё

[root@ovz2 /]# mdadm -Q --detail /dev/md3
/dev/md3:
        Version : 0.90
  Creation Time : Mon Nov 22 19:26:59 2010
     Raid Level : raid5
     Array Size : 3628215808 (3460.14 GiB 3715.29 GB)
  Used Dev Size : 1814107904 (1730.07 GiB 1857.65 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Mon Nov 22 19:26:59 2010
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 0% complete

           UUID : 40c84d78:e7aa45ea:b5b72066:40ad4139
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       1       8       20        1      active sync   /dev/sdb4
       3       8       36        2      spare rebuilding   /dev/sdc4

Но длится это не долго . Через несколько секунд один диск отваливается.

Код: Выделить всё

[root@ovz2 /]# mdadm -Q --detail /dev/md3
/dev/md3:
        Version : 0.90
  Creation Time : Mon Nov 22 19:26:59 2010
     Raid Level : raid5
     Array Size : 3628215808 (3460.14 GiB 3715.29 GB)
  Used Dev Size : 1814107904 (1730.07 GiB 1857.65 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Mon Nov 22 19:27:14 2010
          State : clean, degraded
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 40c84d78:e7aa45ea:b5b72066:40ad4139
         Events : 0.4

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       1       0        0        1      removed
       2       0        0        2      removed

       3       8       36        -      spare   /dev/sdc4
       4       8       20        -      faulty spare   /dev/sdb4

В чём может быть причина, подскажите пожалуйста.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[paix]

О Боже,

raid5 под виртуалки, вы в своем то уме?

Зачем вам этот цирк.
можете два винта загнать в миррор, а на третий сливать бекапы (vzdump)
это лучшее решение в текущей конфигурации.

[sasha181]

Виртуалка там будет одна. OVZ ставится просто для упрощения миграции с другого сервера. А raid 5 нужен, т.к. нужно много места. При этом БД будет не на пятом рейде, а на зеркале, хоть и на этих же дисках.
Понятно что высокой скорости от этого не добъёшься. Со временем БД перенесём на отдельный сервер, а под файлы поставим хранилище, но пока приходится ютиться на одном сервере

[paix]

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

Если вы опишите конкретно конечную тех задачу с указанием имеющихся данных - сможете получить здравый ответ.
А так архитектура крайне бредова и абсурдна.

.... KISS

[snorlov]

Виртуалка там будет одна. OVZ ставится просто для упрощения миграции с другого сервера. А raid 5 нужен, т.к. нужно много места. При этом БД будет не на пятом рейде, а на зеркале, хоть и на этих же дисках.
Понятно что высокой скорости от этого не добъёшься. Со временем БД перенесём на отдельный сервер, а под файлы поставим хранилище, но пока приходится ютиться на одном сервере

Очень интересное решение, разбить диск на 3-и раздела и создать на этих разделах raid5, при этом говорится нужно много места.. вместо 1/1 получаем 2/3...

[sasha181]

имеем сервер с тремя корзинами
3 винта по 2 Tb (Seagate ST32000644NS)
Сайт с хранилищами файлов и видео. Причём для видео хранятся и оригиналы и сконвертированные ролики.
Под это хозяйство и нужно много места.
Кроме того есть весьма прожорливая Mysql , т.к. объём базы большой, а индексы далеко не везде оптимально используются. Мускул весьма часто насилует диски. Отчасти, из-за нехватки памяти. Переносить его на отдельный сервер безусловно нужно, просто сейчас второго сервера нет.
Сейчас сайт висит на VPS и нагружает диски в среднем на 50-70 %. На сервере кроме него ещё штук восемь VPS, из них 2-3 относительно нагруженные.
Вот и решили пока перенести его , чтобы тормозил сам по себе, не мешая другим. К тому же на новом сервере можно добавить памяти для БД и она вздохнёт гораздо легче.

3 диска собираюсь побить на 3 раздела корень и раздел под БД в raid1, а остальное место отвести под raid5 .

Вот если честно , не вижу тут ничего бредового. Ясное дело, что вынести БД на отдельный диск гораздо лучше и правильнее, но к сожалению пока такой возможности нет.

[paix]

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

1. бредовость в том, что вы из 3х нормальных винтов пытаетесь сделать охрененный кастыль (в виде микса рейда1 и рейда5).
Вам для чего нужен рейд то? отказоуйсточивость компонентов? фиг там. В такой конфигурации вылет одного из винтов приведет
скорее всего к полному service level degradation с повышенным вероятностным отказом других компонентов рейда.
(загуглите о надежности raid5, в nginx-ru особенно много матюков по этому поводу).
А учитывая что там еще и база данных на рейд1 на тех же винтах...которая "интенсивно насилует диски".

Диски, знаете ли, имею свойство дохнуть время от веремени. Это селяви.

Про то что это все будет безбожно тормозить, да еще с сложно в реализации и поддержке,- можно не упоминать.

2. Теперь конструктивно.
У вас мало места? выкиньте нахрен схемы с рейдами. Достаточно настроить смарт и мониторить состояние винтов.
Про то что нужно делать бекапы, я думаю, можно не упоминать. Рейд не защищает от необходимости бекапов.

3. На системный винт (там где OS) лучше лишних сервисов не вешать. В идеале там должна находиться одна система. (изолирование дискового I\O от системы). Но поскольку винты нынче большие, лично я предпочитаю на этот системный винт делать бекапы сервисов, контейнеров и т.п. Естественно, удаленно также их нужно синхронизировать.

4. В вашем случае (если 3 винта и хоть тресни),
система + база данных на одном винте, тяжелый контент - на остальных.
Если есть возможность добавить еще один винт для базы , чтобы изолировать дискоинтенсив - идеально.
Ну и бекапчики, бекапчики.

5. Виртуализация. Все нужно использовать по назначению. Легкость миграции\изолирование и т.д. - это все гуд.
Но по факту у вас сильно кастомная система, много статики, нагруженная (с ваших слов) база.
Все это не умещается в концепт виртуалок. (ибо каким макром вы это все через vzdump будете дампить?)
В итоге смысла делать виртуализацию практически никакого. Мускиль, похапе, нжикс можно в два телодвижения поднять и в базе.
Плюс Виртуалки сложнее мониторить и решать проблемы, тюнинговать буфера и т.д. Да и вообще модель memory overcommitment в виртуозо реализована сильно по другому. Это нужно всегда учитывать. (банально в одной виртуалке невозможно запустить столькоже приложений, сколько можно в базовой системе, но можно запустить столькоже в нескольких виртуалках.

6. KISS - Keep It Simple Stupid

[sasha181]

Да уж. Просто у меня опыта с RAID 5 ещё не было. Не знал , что всё так плачевно.
А с RAID 1E кто-нибудь работал ? По идее он по сравнению с raid 1 должен ускорить запись, и с восстановлением проблем теоретически не должно возникнуть.
Просто не хочется ставить БД на один диск, т.к. в случае вылета, есть простой и потеря части данных. А смарт тоже далеко не панацея.

Насчёт миграции контейнера. Просто там много различных особенностей при сборке и настройке софта. На всю эту отладку может потребоваться несколько дней, т.к. уже далеко не всё помнится.
А какова примерно скорость миграции vzmigrate?

Код: Выделить всё

Да и вообще модель memory overcommitment в виртуозо реализована сильно по другому. Это нужно всегда учитывать. (банально в одной виртуалке невозможно запустить столько же приложений, сколько можно в базовой системе, но можно запустить столько же в нескольких виртуалках.

А насколько велика эта разница?

[paix]

1. raid1 - безусловно, идея отличная (если винты позволяют). Скорость записи выше не будет, а вот чтение ускоряется. И надежность.
Если диски позволяют - используйте.
2. raid1 не освобождает от необходимости бекапов.

3. vzmigrate требует определенной интеграции с другим openvz сервером.
Я предпочитаю бекапить контейнеры через vzdump,- получается обычный tar архив. Потом этот архив просто копировать на другую ovz машину и разворачивать через vzresore (входит в комплект vzdump).
Но, это все отлично работает когда обьем контейнера сравнительно не велик.

Если у вас вся фильмопомойка запихнута в контейнер, да еще и база данных большого размера - то чего вы хотите от ovz?
Для нагруженных проектов использование виртуализации особого смысла не имеет.

Вообщем, все это очень сильно зависит от специфики вашего приложения. Если оно чрезмерно сложное, но при этом не потребляет много дискового места и памяти - то можно загнать и в контейнер.

4. на счет memory overcommitment рекомендую загуглить + почитать доки от виртуозо.
Если в двух словах, то это модель распределения памяти. Когда в системе стоит, например, 2г памяти, + 2г. своп, то приложение (например ява) может аллоцировать до 4Г виртуальной памяти, при этом используя существенно меньше.

В контейнере парадигма виртуальной памяти работает по другому. Там приложение, которое попробует аллоцировать более чем 2г памяти (для данной конфигурации) просто не запустится. Или несколько приложений которые в сумме попытаются заалоцировать больше чем 2г.

пример.

Код: Выделить всё

some container  #  ps aux|grep -v grep|grep -c java
5
some container # free -m
             total       used       free     shared    buffers     cached
Mem:          7812       5419       2393          0          0          0
-/+ buffers/cache:       5419       2393
Swap:            0          0          0

Код: Выделить всё

HN # free -m
             total       used       free     shared    buffers     cached
Mem:          7969       7765        203          0        209       1912
-/+ buffers/cache:       5643       2325
Swap:         8001          0       8000

HN # ps aux|grep -v grep|grep -c java
9

Итого, контейнеру выделена практически вся память системы, но запустить там можно отсилы 4-5 java приложений.
В то время как в самой базовой системе можно запустить гораздо больше. И по факту в HN запущен несколько таких
жирных контейнеров.

[sasha181]

С такой особенностью VPS я на практике столкнулся.
Проблема на самом деле в том, что free -m отображает по-умолчанию параметр PRIVVMPAGES. Который , в свою очередь, по сути лимитирует как раз виртуальную память, и его нужно выставлять примерно в 3-4 раза больше, чем необходимо выделить контейнеру физической. По аналогии со swap получается примерно : ram + swap(равный 2ram) = 3ram

Насчёт разделить, согласен. Так и сделаю. Расшарю по NFS пока внутрь виртуалки. В любом случае ведь рано или поздно всю статику на хранилище выносить прийдётся.

Спасибо большое за совет.

[paix]

С такой особенностью VPS я на практике столкнулся.
Проблема на самом деле в том, что free -m отображает по-умолчанию параметр PRIVVMPAGES. Который , в свою очередь, по сути лимитирует как раз виртуальную память, и его нужно выставлять примерно в 3-4 раза больше, чем необходимо выделить контейнеру физической.

да, все хорошо. Но когда у вас в системе 4Г памяти, вы не можете выделить контейнеру больше чем 4 соотвественно.
Поэтому иметь сервер только с одной виртуалкой нерационально.

[sasha181]

Почему же не могу. Если у меня в системе 4 гига памяти и 8 гигов swap, я могу выделить 12 гигов. PRIVVMPAGES - это по сути виртуальная память mem + swap. Всё прекрасно выделится и запустится. А если не хватит физической памяти, начнёт свопиться , как и в обычной системе. Я проверял это. Ну а если начнёт свопиться, значит нужно добавлять памяти.

[paix]

Почему же не могу. Если у меня в системе 4 гига памяти и 8 гигов swap, я могу выделить 12 гигов. PRIVVMPAGES - это по сути виртуальная память mem + swap. Всё прекрасно выделится и запустится. А если не хватит физической памяти, начнёт свопиться , как и в обычной системе. Я проверял это. Ну а если начнёт свопиться, значит нужно добавлять памяти.

мисье, теоретик?

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

[sasha181]

Вы имеете ввиду, что не получится даже назначить PRIVVMPAGES больше чем физическая память, или что не начнёт использоваться swap , когда кончится память?

[paix]

ну выставите наконец контейнеру какое-нибудь астронамическое число памяти (чтобы было больше чем физ. памяти в базовой системе),
например,

Код: Выделить всё

--privvmpages 4000000:5000000

и посмотрите сколько контейнеру будет доступно.

[sasha181]

Сделал.
Внутри контейнера получаем

Код: Выделить всё

[root@ns1 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          7951        606       7345          0          0          0
-/+ buffers/cache:        606       7345
Swap:            0          0          0

Но на HN

Код: Выделить всё

[root@server3 ~]# vzctl set 821134 --privvmpages 41929420 --vmguarpages 20964710
UB limits were set successfully
WARNING: Settings were not saved and will be reset to original values at the next start (use --save flag)
[root@server3 ~]# vzmemcheck -vA
Output values in Mbytes
veid        LowMem  LowMem     RAM MemSwap MemSwap   Alloc   Alloc   Alloc
              util  commit    util    util  commit    util  commit   limit
821136        9.65   48.41  150.14  285.27  528.41  675.27  528.41 1968.41
811005       30.33  193.65  367.56  432.07 2113.65 1177.75 2113.65 7873.65
821142        0.01   48.41    0.01    0.01  528.41    0.01  528.41 1968.41
821134       11.91   96.82  147.17  147.17  352.82  619.41 81990.22 163883.62
821139        3.75   96.82   44.74   67.50 1056.82  311.30 1056.82 3936.82
821141        9.10   96.82  171.33  188.25 1056.82  317.30 1056.82 3936.82
821138        5.68   48.41   34.78  126.22  528.41  497.30  528.41 1968.41
821137        8.70   48.41   43.08   76.38  528.41  130.30  528.41 1968.41
821140       20.68   48.41   94.78  148.14  528.41  582.71  528.41 1968.41
821135       24.22  193.65  624.60  710.28 2113.65 1501.57 2113.65 7873.65
821133        1.47   48.41   20.04   35.76  528.41   23.35  528.41 1968.41
821132        4.60  193.65   81.06  164.25 2113.65  461.09 2113.65 7873.65
821131        5.02   48.41   11.33   22.11  528.41   36.47  528.41 1968.41
811006       62.28  386.50 3664.18 4832.43 4226.50 4897.25 4226.50 15746.50
811004       18.99  417.46  132.97  253.38 3054.93  886.02 3054.93 5665.59
-------------------------------------------------------------------------
Summary:    216.39 2014.28 5587.76 7489.24 19787.75 12117.10 101425.14 230569.19
        3180.00 3180.00 7951.00 24330.00 24330.00 24330.00 24330.00 24330.00
[root@server3 ~]#

Подопытная нода 821134

Я склоняюсь верить выводу vzmemchek на HN. Т.к. отображение памяти внутри VE и без того как-то странно реализовано. Показать например информацию о использовании физической памяти они не способны, а показывают информацию как раз о б использовании виртуальной.

Тут действительно стоит уже пробовать смоделировать ситуацию и проверить на практике.
Будет время , сделаю и отпишусь.

[paix]

ну я так полагаю, что у вас и в базовой то системе 8г памяти стоит. Контейнер ее всю подхватывает, но не более.

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

[sasha181]

Стоит действительно 8 гигов. Только vzmemcheck показывает лимит на физическую память Alloc commit 81990.22 (80 гиг) и Alloc limit (160 гигов).
А подскажите пожалуйста, как можно для теста аллоцировать память в perl например?

[paix]

Стоит действительно 8 гигов. Только vzmemcheck показывает лимит на физическую память Alloc commit 81990.22 (80 гиг) и Alloc limit (160 гигов).
А подскажите пожалуйста, как можно для теста аллоцировать память в perl например?

Alloc commit и limit в базовой системе, кажется, показывают сколько контейнеры сумарно могут аллоцировать памяти. Это нормально.
Нода переходит в режим overcommitment (т.е. когда контейнерам сумарно выделенно больше ресурсов, чем есть в самой базовой ноде).

как аллоцировать память в перлятине я не знаю. гугл в помощь.
но из контейнера не получится аллоцировать более, чем есть в базовой системе.