Доброе время суток всем!
Итак - вопрос на практические аспекты применения или достали меня бухгалтера с медленным 1С (dbf).
Имею в настоящее время могучий сервер, который раздает файлопомойку через самбу (а её ловят АРМы бухгалтеров с 1С). Хотел, вначале, разместить эту 1С-файлопомойку на glusterfs'е (надежность хранения), и раздать её оттуда по самбе, но почти сразу полезли конфликты по блокировкам, индексы начали рушится на глазах и от этой идеи пришлось быстро отказаться. Так что самбовый ресурс с 1С раздается с "локального" серверного диска. Это предистория. А теперь мысли вслух:
1. На сервере нет проблем поднять VirtualBox и в нем поднять Win-сервер.
1.1 Нет проблем поместить vdi-файл с этим виртуальным сервером на glusterfs.
1.2 Нет проблем раздать файловый ресурс этого виртуального сервера внешнему миру. Причем он будет явно виндовый, со всеми их внутренними неописанными заморочками. То есть 1C будет работать с этим виртуальным сервером без каких либо проблем.
1.3. Файловый ресурс виртуального сервера можно создать двояким образом - создать дополнительный vdi-файл потребного объема, поместить его в тот же glusterfs... Чем обеспечим надежность оперативного хранения данных.
1.4. Файловый ресурс виртуального сервера можно поместить на "сыром" диске. И организовать raw-доступ к нему.
2. Вопрос - а стоит ли игра свеч?
2.1. Поднимется ли производительность 1С на юзерских АРМ, если фаловый ресурс затянуть в раздачу от виртуальной машины с офтопиковым сервером?
2.2. Будет ли разница в юзерской производительности, если файловый ресурс размещать в vdi-файле (в плюсах - высокая надежность) или на сыром диске (надежность не смогу обеспечить)?
Сейчас 1С запущенный в виртуальной XP (в конфигурации 2 процессора и 2 гектара памяти), которая получает "базу" 1С через самбовый протокол, работает неспешно. Хотя и побыстрее немного, чем 1С на юзерских компах. Переиндексация базы проходит за 17 минут, а восстановление последовательности за месяц (с закрытием месяца) минут за 40-50. Так что хочется большего....
Я могу, конечно, поставить кучу тестов, но может кто такое уже испытывал? И имеет готовые результаты?
LinuxForum.Fans
Производительность VirualBox
Автор: Cruiser78
9 сообщений
3247 просмотров
1. Поднять вин сервер проблем нет. Проблемы не исключены потом. Например, в одной из предпоследних версий валилась виртуалка от запуска 1с8.1.
1.1 проблем нет, но лучше выделить гостю "диск" в виде реального железа. Файл - это слишком медленно.
1.3
> поместить его в тот же glusterfs... Чем обеспечим надежность оперативного хранения данных.
Скорее не обеспечим, а увеличим. Все относительно, конечно. smile
1.4 кажется, что raw устройство это очень медленно. Не уверен.
> Файловый ресурс виртуального сервера можно поместить на "сыром" диске.
Где-то читал отзыв, что тормоза великие от такой конструкции.
2. Если юзать коробку, то имхо не стоит. Для десктопа она хороша, но имхо и все.
Где-то на опенке давно пробегал тест виртуалок, в котором говорилось и оверхеде.
Коробка вроде как луше все себя показала при работе с vdi, но с точки зрения CPU - была на последнем месте.
К тому же сам постоянно замечал, что в простое коробка жрет CPU. Причем, все равно, что за ядро.
KVM + virito (LVM partition as disk) = счастье?
1. Поднять вин сервер проблем нет. Проблемы не исключены потом. Например, в одной из предпоследних версий валилась виртуалка от запуска 1с8.1.
Это исключено. У меня, как видно из стартового топика 1С 7.7. И мне нужна скорострельная виртуалка только для одной, точнее, для полутора целей. Главная - обеспеить скорострельность административной работы в 1С, то есть скорость проведения регламентных операций - переиндексация, восстановление последовательностей, удаление помеченных объектов. Админская 1С у меня развернута именно в VB на могучем сервере. Если удастся поднять скорострельность админской машины, то возможно (но не обязательно) поднимется скорострельность и юзерских АРМов. Сейчас она меня не устраивает. На гораздо более слабом сервере, но в родной винде оно работало несколько пошустрее. А сейчас - бабло вложено в хороший сервер, а прироста производительности (то, что можно реально продемонстрировать)- нет. А это неправильно... Вот я и ищу пути.
1.1 проблем нет, но лучше выделить гостю "диск" в виде реального железа. Файл - это слишком медленно.
Вот именно это меня и интересует. Вот только более интересно - насколько слишком медленно. То есть хочу иметь следующее:
1. Время операции X в 1С при раздаче dbf-ресурса самбой с "локального" диска сервера =1;
2. Время операции X в 1С при раздаче dbf-ресурса самбой с glusterfs этим же сервером = ?
3. Время операции X в 1С при раздаче dbf-ресурса виртуальной вынью, поднятой на этом же сервере:
3.1 из VDI-файла = ?
3.2. из сырого диска = ?
Вот тогда оно будет похоже на инженерный подход.
1.4 кажется, что raw устройство это очень медленно. Не уверен.
Где-то читал отзыв, что тормоза великие от такой конструкции.
Может я неправильно применил термины, но у меня осталось ощущение, что raw-диск и есть диск (раздел диска) "сырой" (предварительно неразмеченный), который подключается к VB напрямую. Отдельной командой. И он должен работать, по идее, максимально быстро... Хотя, что они там понаписали?
сам постоянно замечал, что в простое коробка жрет CPU. Причем, все равно, что за ядро.
Я замечаю обратное. У меня на сервере коробка постоянно (днем) в простое. А системный монитор кажет (когда я на него смотрю, что процессоры сожраны не более, чем на 5%. Может быть коробка отжирает ровно столько, сколько ей положено и насыщается? Тогда и CPU больше для жизни остается?
KVM + virito (LVM partition as disk) = счастье?
А вот не знаю, не пробовал.
[quote=zerg]KVM + virito (LVM partition as disk) = счастье?
А вот не знаю, не пробовал.[/quote]
Попробуйте :)
О терминах не спорят. О них договариваются. И если мы договоримся об одинаковом толковании термина, то и предмет спора пропадет :-).
В данной статье под raw-девайсом (кстати, тоже сырым) понимается _символьный_ девайс без кэширования. То есть достаточно узкое толкование. Как же мы тогда назовем обычный неразмеченный жесткий диск, который и блочный и с кэшами встроенными. Я под сырым диском понимал не символьный raw, а неразмеченный жесткий диск (или нераспределенный его раздел. Ктати, и Oracle, если мне не изменяет память, тоже применяет подобный термин именно к неразмеченным и нераспределенным дискам (и делает там свою "файловую" систему).
Вообще, остаться на VB, не попробовав KVM/XEN/VMWARE - вот это будет точно ошибкой.
Совершенно согласен. Цели моих поисков -
1. максимальная производительность работы в виртуалке 1С 7.7 на файло-помойке.
2. отказоустойчивость файлопомойки и виртуальных серверов.
По п. 1 - в поиске, но вот промежуточные результаты для VB:
Сервер "приложений" - 8 ксеоновых ядер, 4 гектара памяти. VB сконфигурирован на использование 2 ядер и 2 гигабайт памяти. Сетевые адаптеры - гигабитные. При работе VB используется памяти не более 3.2 гигабайта и 660 мегабайт свопа (без VB свопа столько же).
Glusterfs - развернут на 2х нодах, первая - этот же сервер, вторая - сервер на Intel Pentium Duo с 2мя гектарами памяти (кроме поддержки glusterfs'а и LDAP'а на нем нет ничего - то есть ресурсов достаточно). Связь между ними по гигабитной сети. Glusterfs монтируется на сервере приложений с 1Gb performance/io-cache.
Гостевая ось на сервере приложений - Windows XP SP3.
Процедура измерения: в пакетном режиме запускаем конфигуратор на индексацию dbf-базы 1С. База размещена физически на этом же могучем сервере приложений и раздается юзерям (в ЛВС) через samba. VDI-диск виртуальной машины размещен непосредственно на сервере. Общий объем базы - 3.5 гигабайта, dbf-файлов - 2.2 гигабайта
Варианты измерений:
1. База примонтиронтирована в VB по протоколу samba. Переиндексация занимает 17 минут.
2. База примонтирована в VB как "общая папка". Переиндексация занимает 13 минут.
3. База размещена в vdi-файле самой коробки (на её букве С:\). Переиндексация заняла 10 минут.
4. База размещена в glusterfs и примонтирована к VB по самбе. Переиндексация занимает 19 минут.
5. База размещена в glusterfs и примонтирована к VB как "общая папка". Переиндексация занимает 15 минут.
6. Измерений, когда база лежит в сыром HDD, и примонтирована к VB, не проводилось. Пока не имею такой возможности. Для этого надо уменьшить один из томов юникса (LVM) а я этого пока не умею. Следовательно - боюсь пока этой процедуры.
7. Измерений, когда VB сам размещен в glusterfs (это моя цель - параноидальная надежность) пока не проводилось. Это - завтра...
Во время этих измерений загрузка "процессора" сервера приложений (их там 8 штук) не больше 45%.
Резюме: Набольшая скорость обработки - "локальная". То есть когда 1С считает, что база локальная и не пользуется сетью. Надо будет, таки, натравить её на сырой диск, а не на VDI-файл....
На втором месте по производительности - "общая папка" VirtualBox'а. К сожалению, файловый доступ по протоколу samba к тому же самому - курит в сторонке. Собственно это и понятно - дополнительное преобразование никому на пользу не шло. Но чтобы так... Тормозить более чем в потора раза??? :-( Аз есмь в печали...
Похоже, что от самбы (под 1C) придется отказаться. После тестирования скорострельности ремутного АРМа на различные источники раздачи данных, естественно. Хотя - здесь начинает играть рояль по п.2 - отказоутойчивость. Все таки хочу файло-помойку с базой 1C и её раздачу иметь в glusterfs'е, а не в сыром, пусть и в RAID1, диске... Самба может очень хорошо ездить с хоста на хост (по heartbeat'у), в отличие от раздела диска с данными...
Для этого надо уменьшить один из томов юникса (LVM) а я этого пока не умею.
в дебиане есть пакет system-config-lvm - работа с LVM в графике намного приятнее и удобнее.
специфических вещей не умеет правда (вроде создания не линейного тома) но урезать, увеличивать, присоединять и прочее очень удобно.
Войдите или зарегистрируйтесь, чтобы ответить.
