Народ, нужен совет. Виртуалка, SQL и дисковые массивы.

Ситуация:

Есть сервер HP DL 180 (8 core CPU Intel/6 RAM/RAID Controller/10 HDD SATA + 2 Option/2 LAN)

Рассматриваем как вариант СЕРВЕРА 1С:Бухгалтерия (12 users) + возможно на будущее 1С:Документооборот (100 users).

ПО:

- Виртуальная ОС Proxmox 1.6
- Гостевые ОС (как варианты):
    1. Ubuntu 10.04 Server x64 + Postgree SQL (Etersoft) + 1Cv8
    2. Windows 2003 Standart SP2 Rus x86 + MS SQL 2005 Rus + 1Cv8
- Доступ с клиентов к серверу через веб-фейс

БД-ых в любом случае, физический, состоит из 2-х файлов. Самой БД и журнала транзакции.

Внимание вопрос:

- Как эффективнее разбить существующую дисковую подсистему для достижения максимальной производительности работы этого зоопарка: ВиртОС, ГостОС и БД?

У самого пока 2 варианта:
1. либо выделить все 10 HDD (7200) под 1 RAID-10 производительность всего дискового массива = х5.
2. либо (2 HDD в RAID-1 (Proxmox + ОС) производительность массива = х1) + (4 HDD в RAID-10 (БД) производительность массива = х2) + (4 HDD в RAID-10 (журнал) производительность массива = х2).

Пока, принимая во внимание рекомендации разных 1с-ников и форумов, придерживаюсь 2-го варианта, но это как кажется трудно реализуемо. Хотя Proxmox по дефолту работает с LVM.
Какие будут мысли?

Комментарии

Изображение пользователя Marat.

В целом, - победил!)) Но,

В целом, - победил!))
Но, поставленный вопрос, остается открытым.

Изображение пользователя Marat.

Айрат, если можно, поправь

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

Изображение пользователя doom2_imp.

офтоп, Марат, ну как Proxmox

офтоп, Марат, ну как Proxmox себя показывает?

Изображение пользователя Marat.

По данной теме, пока

По данной теме, пока разобрался с RAID-массивами и работой LVM на них.
Опенказан, как думаешь, на чем крутиться?;)
Как говорил manofring, - вещь!

Изображение пользователя doom2_imp.

ясненько =)

ясненько =)

Изображение пользователя admin.

proxmox - реально вещь.

proxmox - реально вещь. рекомендую.:)

Изображение пользователя doom2_imp.

ну если минздрав

ну если минздрав рекомендует.. =)

Изображение пользователя manofring.

1. либо выделить все 10 HDD

1. либо выделить все 10 HDD (7200) под 1 RAID-10 производительность всего дискового массива = х5.
2. либо (2 HDD в RAID-1 (Proxmox + ОС) производительность массива = х1) + (4 HDD в RAID-10 (БД) производительность массива = х2) + (4 HDD в RAID-10 (журнал) производительность массива = х2).

fart я рад что ты таки узнал что такое proxmox, по правде скажу посмотрев RHEV я долго ржал...кстати красношляпники рьяно доказывали что это рулез...млин когда я сказал что у меня на 4 писюках подобная система крутится уже 2,5 года...вы бы видели их лица...риал. Сорри за офтоп - но proxmox реально уделал RHEL и по времени и по фичам..Теперь про рейды, зеркало под ОС и proxmox это зе гуд, but one no, был у меня такой случай (сейчас я буду петь про то что шо бы не юзали "железные рейды") компак (уже не помню что за модель, напольник, башня) крутился лет так эдак несоврать 5 а может 4....и млин стоял на нем DC win2000, потом роль дц перенесли на IBM помощнее а этот оставили под файлоПомойку....ну так вот...сдача отчетов в ПФР, все все сдали...а там помимо этого была база от досовской проги, причем в базе были данные .... ну не супер важные....но конец года...ну вообщем понятно и бац оно упало...сцуко..млин сам сервак живой...и раиды живые, тока отказала система винтиляторов...есть такая гадкая сволочь - датчик Хола...:) крутится - все ок...бивис не стопит процы...да о чем я?..Ах да..толи всю ночь толи весь день...два админа или дебила (один из них я)...сидели с пылесосом и и направляли струю воздуха на эти два "поломанных" вентилятора...2 из 6...а сервак потихоньку сливал данные в сеть...уж незнаю почему но скорость на ethernet упала унего до 10 мегабит...и гигов 200 мы сливали так долго...а что делать - сказали если не "вытащите"...вам пи...ц :) Ну мы хитрые взяли два пылесоса..много много пива...я потом оглох на пару дней на одно ухо...до этого никогда не курил в серверной...Ах о чем я опять....Все было бы зашибись...если бы рядом стоял такой же компак с идентичными (маловероятно) параметрами раид контроллеров ...мы бы просто вытащили витнты и присунули бы туда...но...его не было и времени не было...

Вывод...используй все что угодгно - soft RAID, mirror LVM, soft RAID+LVM....и тд...выдрал и поставил в рыдошний сервак (если он есть)...
Вот такая вот история...

Это я к тому проксмокс ты всегда переставиш с компашки...а данные...ну я понимаю...сервисные центры и тд...а также знаю скока стоит вытащить данные с таких винтов..а уж с поломанных скока стоит я уж умолчу..

между нами говоря - сколько бы не усирались "правильные" админы - разница между софтовы м и железным рейдами на таких мегаПроцах кои стоят в current серверах....достигает 1-3%

http://forum.ixbt.com/topic.cgi?id=11:31329
http://forum.ixbt.com/topic.cgi?id=11:30301

Изображение пользователя admin.

>>сколько бы не усирались

>>сколько бы не усирались "правильные" админы - разница между софтовы м и железным рейдами
двумя руками за софтовый. кто бы что не говорил, но пробывал и то и то.
только софт-raid.

правило номер 1 - разделяй ОС

правило номер 1 - разделяй ОС и данные. мы в своей школе (см профайл) обычно так делаем.
посему - 2 в однёрку и желательно без LVM (потребности особой нет, проблем при диагностике больше) под систему, остальные в 10-ку и LVM отрезая и двигая тома по мере необходимости (ext2online и иже сними снизят время простоев)

по поводу аппаратных рейдов - надёжность более чем. если HP - там есть такое понятие как foreign raid - даже рейды 5-ки и 6-ки аккуратно переставленные в те же позиции на свежий сервак-донор заводятся без вариантов и допнастроек, проверено завучем.

по поводу пылесосов - на них лучше шарики от пинг-понга прикольно так балансировать (на выдув), а 2 сдохших вентилятора из 6 - это штатно, серваку похуй, он поймёт. если они рядом и прямо напротив радиатора проца, а в серверной +35 и выше - махнуть местами рассредоточив сдохшие и не париться, Сервер он умный, он поймёт когда надо загудеть (при включении сервера вентиляторы ж позлее гудят чем обычно? это они на полную мощь работают )

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

а по поводу ссылок - нас на уроке литературы учили читать тексты вдумчиво - в постановке первой задачи я нашёл

Аппаратный массив в большинстве своем непереносим.
Т.е. к риску потери данных при выходе из строя диска добавляется риск потери данных при
выходе из строя самого RAID-контроллера. Естессно, я имею ввиду бытовые реализации для домашнего ПК. Реализации для домашнего ПК - это полусофтовые, ну как винмодемы -я про них мало помню, в садик еще ходил, но там вроде тоже на ОС/ПО было завязано, отсюда и малая разница в производительности и высокий процент отказов

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

PS - если нет донора - то достаточно развернуть актуальные бекапы (они же отдельно от сервака? и даже актуальные?) на любом компе с линуксом и подходящим дисковым пространством за время их разворачивания в 1-2-3 часа.

Изображение пользователя Marat.

manofring wrote:.....Теперь

manofring wrote:
.....Теперь про рейды, зеркало под ОС и proxmox это зе гуд, but one no, был у меня такой случай (сейчас я буду петь про то что шо бы не юзали "железные рейды")...

....Вывод...используй все что угодгно - soft RAID, mirror LVM, soft RAID+LVM....и тд...выдрал и поставил в рыдошний сервак (если он есть).....

Это же не единственная система сохранности данных. Бекапы (в гостевых ОС, перекрестные и др), кластеры+drbd и тд.
Особенно в автоматизированных системах, где критично время простоя.

Изображение пользователя Marat.

Timur wrote:правило номер 1 -

Timur wrote:
правило номер 1 - разделяй ОС и данные. мы в своей школе (см профайл) обычно так делаем.
посему - 2 в однёрку и желательно без LVM (потребности особой нет, проблем при диагностике больше) под систему, ...

Proxmox, по дефолту, на том RAID-1 массиве, куда ставится, создает 2 раздела: ext3 (/boot) = примерно 512 Мб и остальное LVM, где и стоит наш Демьян ВиртОС. Там же в LVM-е хранится и все остальное (вирт.машины с гостевыми ОС и тд).
Согласен, особой потребности в LVM нет. Но в плане дефолтных настроек Proxmox-а не хотелось бы что то менять.

Timur wrote:
....остальные в 10-ку и LVM отрезая и двигая тома по мере необходимости (ext2online и иже сними снизят время простоев)...

производительность дискового массива в 8 HDD RAID-10 = x4 конечно привлекает, но опять же судя по мнениям и той логике, что при одновременно большом количестве обращении и к БД и к журналу транзакции их, для повышения общей производительности работы, лучше разнести на физически разные дисковые массивы.
конечно, в плане обслуживания данных на этих массивах задача обработки усложниться.

Timur wrote:
по поводу софтовый vs аппаратный - разница процентов в 20 при активных дисковых операциях и дополнительному поводу греться процу оставляя меньше свободных ресурсов. На рейд-контроллерах чипики такие припаяны с памятью мегабайт на 512 который сильно винты разгружают, и еще батареечка такая уложена на проводочке и позволяет при внезапном отключении питания весь кешик на винты скинуть и дисковые операции завершить.

это таки кошерно.
однако, учитывая что на продакшн серверах даже серьезные ИБП ставятся и есть какой то запас времени для завершения все тех же дисковых операции, вознивает такой вопрос:
- Можно ли будет, при достижении уровня критического разряда ИБП, гостевой ОС (допустим Ubuntu) автоматически завершить работу всех приложении и работу самой гостевой ОС. А если, каким то волшебным образом еще и работа вирт.ОС завершится, то это будет просто супир.

Изображение пользователя doom2_imp.

> Согласен, особой

> Согласен, особой потребности в LVM нет.
А если так - Backup lvm-based дисков виртуальных машин http://aliech.pp.ru/node/15 ?

> - Можно ли будет, при достижении уровня критического разряда ИБП, гостевой ОС (допустим Ubuntu) автоматически завершить работу всех приложении и работу самой гостевой ОС. А если, каким то волшебным образом еще и работа вирт.ОС завершится, то это будет просто супир.
Если ИБП поддерживает linux. Там же должен быть COM или USB шнурок, который втыкается в комп и пожно мониторить состояние ИБП. vbox может рулить корректным выключением гостевых систем, другие системы виртуализации тоже должны поддерживать такой функционал.

Изображение пользователя Marat.

Николай, от спасибо, за

Николай, от спасибо, за сокращение времени гугления!)
Буду вникать.

Изображение пользователя doom2_imp.

незачто, Марат )

незачто, Марат )

Proxmox по дефолту, редхат по

Proxmox по дефолту, редхат по дефолту, убунту по дефолту - это для сферического юзера/админа со сферическими потребностями. Как нужно тебе (с LVM или без) надо решать под конкретные задачи.

О производительности надо думать когда есть конкретная задача. Это может быть база с малым количеством записей и чуть большим количеством чтения а важно только сохранность и доступность данных. могут быть десятки разных требований и условий и в соответствии с ними надо решать как бить диски и какие ставить рейды. Исходя из описанной - выводы сделать сложно.

Про продакшны - на серьезных продакшн-площадках нет ибп, толку от него на 15 минут. в отдельных аккумуляторных серьезные аккумуляторы не дают сдохнуть зданию несколько часов, а дизель заводится автоматом через секунду после пропадания электричества. Ибо при рядах стоек и отключенном кондиционировании железо само собой начнёт отрубаться от перегрева помещения минут через 20-30, все сервера с двумя блоками питания от разных фаз и тд - даже тогда эти батарейки нужны ибо ничто не спасает от человеческого фактора, ошибок и просто долбоёбов дёргающих не за те провода. Участок шнура от ИБП - это тоже точка отказа, как и сгоревший (например взорвавшийся аккумулятор) ИБП. Это еще одна точка отказа которая оправдывает наличие дополнительного питания для рейд-контроллера для корректного сброса кеша даже после отрубания остальной части сервака.

Изображение пользователя Marat.

Timur wrote:Proxmox по

Timur wrote:
Proxmox по дефолту, редхат по дефолту, убунту по дефолту - это для сферического юзера/админа со сферическими потребностями. Как нужно тебе (с LVM или без) надо решать под конкретные задачи.

О производительности надо думать когда есть конкретная задача. Это может быть база с малым количеством записей и чуть большим количеством чтения а важно только сохранность и доступность данных. могут быть десятки разных требований и условий и в соответствии с ними надо решать как бить диски и какие ставить рейды. Исходя из описанной - выводы сделать сложно.


Если с задачами нет четкого понимания, ни у руководства, ни тем более у ИТ-шников (от чего оталкиваться) тут нужен системный подход. Хочеться предусмотреть, по возможности, задачи которые могут возникнуть в будущем, при эксплуататции данного сервера.
Это как с выбором железа. Человек, к примеру, хочет Майбах, а денег у него хватает только на корпус от него. В результате, при определенных фин.вложениях он сможет ездить на продукте своей мечты, но если бы он взял корпус от запорожца, то тут другая песня...
Для этого система в целом должна быть гибкой. Поэтому и LVM.
Timur, в целом точка зрения понятна.

Изображение пользователя Marat.

Timur wrote:Про продакшны -

Timur wrote:
Про продакшны - на серьезных продакшн-площадках нет ибп, толку от него на 15 минут. в отдельных аккумуляторных серьезные аккумуляторы не дают сдохнуть зданию несколько часов, а дизель заводится автоматом через секунду после пропадания электричества. Ибо при рядах стоек и отключенном кондиционировании железо само собой начнёт отрубаться от перегрева помещения минут через 20-30, все сервера с двумя блоками питания от разных фаз и тд - даже тогда эти батарейки нужны ибо ничто не спасает от человеческого фактора, ошибок и просто долбоёбов дёргающих не за те провода. Участок шнура от ИБП - это тоже точка отказа, как и сгоревший (например взорвавшийся аккумулятор) ИБП. Это еще одна точка отказа которая оправдывает наличие дополнительного питания для рейд-контроллера для корректного сброса кеша даже после отрубания остальной части сервака.

Это да, в сложных системах, условии очень много.
Многие из них не понимал, поэтому и не учел. Спасибо за подсказку.

в случае, если руководство не

в случае, если руководство не понимает (а оно и не должно понимать что такое рейд и куда складывать журнал) надо продумать различные варианты и представить их руководству с обоснованием.
утрируя - есть задача сервака, ты приносишь:
А) освободился писюк, ставим на него линукс и засовываем под стол. Производительность низкая, отказоустойчивость низкая, железо так себе, проблемы с сервером начиная от швабры уборщицы.
B) в освободившийся писюк добавляем памяти и винтов и убираем в отдельное помещение, уборщицу инструктируем, кабеля укладываем без касания пола, писюк поднимаем выше уровня пола на случай если помещение будет залито водой.
...
H) покупаем полупромышленный сервер, снабжаем ибп, настраиваем завершение по сигналу от ибп
,,,
Z) арендуем сервер на промышленной площадке (датацентр), организуем нужные каналы до этого центра.

Примерный бюджет и примерные требования к задаче IT так или иначе известны и исходя из них можно неподходящие варианты исключить, предоставив руководству 3-5 обоснованных с ценами и описанием разницы.

Изображение пользователя Marat.

Timur wrote:в случае, если

Timur wrote:
в случае, если руководство не понимает (а оно и не должно понимать что такое рейд и куда складывать журнал)

Не припомню, где я упоминал, что руководство должно учитывать задачи технологического и технического плана конкретного отдела? У них своих проблем хватает.

В моем случае имелось ввиду, что:
- Бардак - нельзя автоматизировать. (с)
Поэтому приходится с ним бороться.

style="display:inline-block;width:728px;height:15px"
data-ad-client="ca-pub-4493870272388852"
data-ad-slot="6622567932">