Re: виртуализация сервера
Wed, 26 Feb 2014 01:08:40 +0400 Mikhail A Antonov mikh...@antfam.ru wrote: Итого: Для людей, не особо разбирающихся во внутренностях виртуализации (коими часто является саппорт) - proxmox самое оно. Для людей, которым ни proxmox, ни virt-manager не нужны потому что они на столько суровы, что помнят половину параметров kvm на память - собсно proxmox не требуется, но позволяет сэкономить время на мелких действиях. Один фиг что с virt-manager, что с proxmox если что-то пошло не так - можно руками запустить kvm с нужными параметрами и починить всё. В повседневной жизни - proxmox удобен и тем и другим, ИМХО. Добавлю еще, что в pve из коробки работает кластер. На голом debian кластер из пакетов в squeeze без мата и пинков не поднимался (точнее поднимался, но умел вставать в разные неприличные позы от нечего делать). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140303164350.26aaf487@snail
Re: виртуализация сервера
26.02.2014 3:15, Alex Kuklin пишет: On 25.02.2014 22:06, Mikhail A Antonov wrote: 25.02.2014 19:50, Munko O. Bazarzhapov пишет: proxmox вроде бы стал платным ? или есть бесплатные варианты, в чем они обрезаны от платных? Ничем кроме надоедливого сообщения он не отличается. И то, это сообщение легко убирается в js. А что такого дает proxmox, чего не дает virt-manager для kvm и vzctl для openvz, если речь идет о виртуализации небольшого числа систем? Я для себя не нашел причин городить огород с proxmox. Даёт openvz-совместимое ядро для wheezy. Долго тормозил с обновлением сервера, пока добрые люди не подсказали подключить репозиторий proxmoxa. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53154367.2000...@nskes.ru
Re: виртуализация сервера
Здравствуйте, Vladimir Skubriev Ответ на Ваше письмо от 26.02.2014 18:55 Во первых покажите разбивку диска, хотя бы fdisk -l /dev/sda # fdisk -l /dev/sda Disk /dev/sda: 999.7 GB, 999653638144 bytes 255 heads, 63 sectors/track, 121534 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00074166 Device Boot Start End Blocks Id System /dev/sda1 * 1 119543 960226304 83 Linux /dev/sda2 119543 121535159948815 Extended /dev/sda5 119543 12153515994880 82 Linux swap / Solaris Есть железный сервер. Хочется его виртуализировать. Жесткий диск там размером 1тб, при переносе содержимого при помощи dd возникает вопрос куда и как его писать ... В связи с этим вопрос - как все таки правильнее сделать виртуальную машину? в качестве эксперимента пробовал сделать через VBoxManage convertfromraw с записью на nas ... потерпел неудачу, оно делает наверное копию диска посекторно, в результате чего через примерно 12 часов переписывания север завис почти намертво простое копирование тоже ни к чему хорошему не привело быстрее наверное будет его по пакетам перешерстить и поднять на виртуалке :) -- Oleg -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530ec99f.4000...@gomelpromstroy.by
Re: виртуализация сервера
Сильно зависит от операционной системы на сервере. Если linux, то просто перелить файлы любым доступным методом (промежуточный диск, rcp, rsync и т.д.) и сделать загрузочным. В вики proxmox есть приличное описание как мигрировать с железки в виртуалку. (http://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE) 2014-02-25 18:31 GMT+06:00 Oleg Litvinov o...@gomelpromstroy.by: Добрый день! Есть железный сервер. Хочется его виртуализировать. Жесткий диск там размером 1тб, при переносе содержимого при помощи dd возникает вопрос куда и как его писать ... В связи с этим вопрос - как все таки правильнее сделать виртуальную машину? -- Oleg -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530c8d16.7040...@gomelpromstroy.by -- Евгений Самусев.
Re: виртуализация сервера
proxmox вроде бы стал платным ? или есть бесплатные варианты, в чем они обрезаны от платных? Munko O. Bazarzhapov JabberID: v...@aginskoe.ru mail: vec...@gmail.com 25 февраля 2014 г., 23:12 пользователь Eugene V. Samusev samu...@gmail.comнаписал: Сильно зависит от операционной системы на сервере. Если linux, то просто перелить файлы любым доступным методом (промежуточный диск, rcp, rsync и т.д.) и сделать загрузочным. В вики proxmox есть приличное описание как мигрировать с железки в виртуалку. (http://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE) 2014-02-25 18:31 GMT+06:00 Oleg Litvinov o...@gomelpromstroy.by: Добрый день! Есть железный сервер. Хочется его виртуализировать. Жесткий диск там размером 1тб, при переносе содержимого при помощи dd возникает вопрос куда и как его писать ... В связи с этим вопрос - как все таки правильнее сделать виртуальную машину? -- Oleg -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530c8d16.7040...@gomelpromstroy.by -- Евгений Самусев.
Re: виртуализация сервера
Oleg Litvinov o...@gomelpromstroy.by writes: А Добрый день! Есть железный сервер. Хочется его виртуализировать. Жесткий диск там размером 1тб, при переносе содержимого при помощи dd возникает вопрос куда и как его писать ... В связи с этим вопрос - как все таки правильнее сделать виртуальную машину? Уважаемый Олег, dd-шить живой сервер - это нехорошо, потому что у Вас получится солянка из старых и новых данных. Лучше пользоваться rsync-ом. Как только всё синхронизируете - прерываете работу сервера, и производите подмену на виртуалку. В идеале простоя сервера не будет, а клиенты не заметят подмены. Разве что активные соединения Как именно виртуализировать - зависит от типа виртуальной машины, которую Вы собираетесь использовать. Обычно это файл фиксированного размера, содержащий файловую систему, но может быть и иначе. Из современный виртуалок очень хорошо себя зарекомендовал KVM, если верить новостям с OpenNet. У меня сейчас виртуалки крутятся на Xen в облаке ДЦ Oversun. Впечатления хорошие. pgpFYZdUhcU_d.pgp Description: PGP signature
Re: виртуализация сервера
25.02.2014 19:50, Munko O. Bazarzhapov пишет: proxmox вроде бы стал платным ? или есть бесплатные варианты, в чем они обрезаны от платных? Ничем кроме надоедливого сообщения он не отличается. И то, это сообщение легко убирается в js. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: виртуализация сервера
On 25.02.2014 22:06, Mikhail A Antonov wrote: 25.02.2014 19:50, Munko O. Bazarzhapov пишет: proxmox вроде бы стал платным ? или есть бесплатные варианты, в чем они обрезаны от платных? Ничем кроме надоедливого сообщения он не отличается. И то, это сообщение легко убирается в js. А что такого дает proxmox, чего не дает virt-manager для kvm и vzctl для openvz, если речь идет о виртуализации небольшого числа систем? Я для себя не нашел причин городить огород с proxmox. -- Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530cf9c4.6040...@kuklin.ru
Re: виртуализация сервера
26.02.2014 00:15, Alex Kuklin пишет: On 25.02.2014 22:06, Mikhail A Antonov wrote: 25.02.2014 19:50, Munko O. Bazarzhapov пишет: proxmox вроде бы стал платным ? или есть бесплатные варианты, в чем они обрезаны от платных? Ничем кроме надоедливого сообщения он не отличается. И то, это сообщение легко убирается в js. А что такого дает proxmox, чего не дает virt-manager для kvm и vzctl для openvz, если речь идет о виртуализации небольшого числа систем? Я для себя не нашел причин городить огород с proxmox. Для kvm: Имею опыт работы с virt-manager около двух лет на 7 серверах. 5 из них переехали на proxmox и ещё 3 добавились сразу на proxmox. Сервера в большинстве своём для разничных организаций, но кластер и я успел попробовать в пределах одной сети. И как оказалось, proxmox поставить поверх дебиана и рулить машинами через него выходит удобнее чем возня с virt-manager. Им (proxmox) удобнее управлять машинами, у него есть вёб-консоль, и его не штырит в отличии от virt-manager при попытке добавить\удалить диск для виртуалки, подключившись virt-manager с локальной машины к серверу с виртуалками. Запускать virt-manager на сервере с виртуалками - совсем не удобно. Особенно если под руками только винда с putty в лучшем случае. Очерёдность автозапуска виртуалок для libvirt (с коей связывается virt-manager) меняется путём переименовывания, тогда как proxmox это делает легко и непринуждённо прямо через вёбморду. Если у тебя нет под рукой машины, где можно запустить virt-manager без танцев с бубном - управление машинами перестаёт быть скучным. Особенно если надо объяснить кому-то по телефону какие кнопки жать чтобы попасть в консоль к виртуалке. proxmox умеет авторизацию в AD и авторизацию вообще. В логах замечательно видно кто бросил валенок на пульт. proxmox из вёбморды даёт возможность делать снапшоты и бэкапы. Сам не пользовался, но ручки на видном месте. Если машины только для одного себя любимого - там хоть из rc.local запускай kvm с нужными параметрами. Если машинами рулить нескольким людям (например саппорту дать доступ к конкретно одной машине) - proxmox. Для ovz: Мне vzctl был и есть удобен. Там гуй ни к чему, в отличии от, например, виндовых машин внутри kvm. Но раз уж умеет один интерфейс рулить и ovz и kvm - чего бы и не воспользоваться? Пользоваться virt-manager для ovz не пробовал ни разу. Итого: Для людей, не особо разбирающихся во внутренностях виртуализации (коими часто является саппорт) - proxmox самое оно. Для людей, которым ни proxmox, ни virt-manager не нужны потому что они на столько суровы, что помнят половину параметров kvm на память - собсно proxmox не требуется, но позволяет сэкономить время на мелких действиях. Один фиг что с virt-manager, что с proxmox если что-то пошло не так - можно руками запустить kvm с нужными параметрами и починить всё. В повседневной жизни - proxmox удобен и тем и другим, ИМХО. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Виртуализация
03.04.2013 20:20, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 26.03.2013 18:42, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. You could say: localtime() is not a reentrant function. Right. But why does it hang ? Let???s look into libc source code. On our Debian GNU/Linux 6.0 machine the interesting part is in eglibc-2.11.3/time/localtime.c И что тут смешного? Со всеми бывает. Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает снятия блокировки прерванного localtime(). Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была рассчитана на многопоточность, а разработчики предпочитали отделываться добавлением костылей. Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, объясните? Я не в теме. В signals handler'е нужно устанавливать флаг или завершать работу, в зависимости от сигнала. А тут у нас геройство такое - мы в XXI веке осознали, что так как мы делаем - делать низзя. Хотя про это пишут во всех HOWTO по обработке сигналов. Типичный индусский код. Ну я понял уже... Ладно, по крайней мере, как-то работает, а это лучше, чем ничего. Стоит надеяться, что когда-то они произведут рефакторинг... Я вскоре собираюсь ставить 2-й и перенести конфигурацию с тестового 1.8. На данный момент, всё-таки ограничусь Zabbix. Поищу патч от Яндекс. Если найду - хорошо. В любом случае, пока что, не очень критично. Не найдешь ты их. Есть у меня предположение, что там от забикса только название осталось. Насчёт того, что только название, - не уверен. Но то, что в публичном доступе нет, скорее всего. Как ни печально. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515d8f5e.3060...@yandex.ru
Re: Виртуализация
03.04.2013 07:24, Stanislav Vlasov пишет: 2 апреля 2013 г., 23:27 пользователь Артём Н. artio...@yandex.ru mailto:artio...@yandex.ru написал: 02.04.2013 08:13, Stanislav Vlasov пишет: 4. Коммутатор (говорят, что возможно найти лишний). Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. Хм... Разве что сумеете обеспечить связь каждый с каждым без него, причём с двойным резервированием. Мда, проще найти коммутатор. Просто раньше они, говорят, валялись кучкой, а сейчас найти не получается. shop.nag.ru http://shop.nag.ru в помощь. Правда, не знаю, насколько быстро. Не пригодилось. Нашёл целую стопку коммутаторов 3Com. Взял один. С тем, куда устанавливать ОС на СХД, похоже, тоже проблемы нет. Один терабайтник забрали. :-\ И заменили полудохлым 320 Гб. Обещали вернуть, но сомневаюсь. Так что, объём уменьшился до 10 Тб, чего впрочем, должно хватить (а, вообще, дальше не мои уже проблемы будут). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515d9008.8060...@yandex.ru
Re: Виртуализация
Артём Н. artio...@yandex.ru wrote: 26.03.2013 18:42, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. You could say: localtime() is not a reentrant function. Right. But why does it hang ? Let???s look into libc source code. On our Debian GNU/Linux 6.0 machine the interesting part is in eglibc-2.11.3/time/localtime.c И что тут смешного? Со всеми бывает. Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает снятия блокировки прерванного localtime(). Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была рассчитана на многопоточность, а разработчики предпочитали отделываться добавлением костылей. Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, объясните? Я не в теме. В signals handler'е нужно устанавливать флаг или завершать работу, в зависимости от сигнала. А тут у нас геройство такое - мы в XXI веке осознали, что так как мы делаем - делать низзя. Хотя про это пишут во всех HOWTO по обработке сигналов. Типичный индусский код. Жабикс крив по своей внутренней идеологии и организации. Унутре оно всё однопоточное, из-за этого обвешано нелепыми таймаутами. Импорт хостов с темплейтами может занимать несколько часов, при этом только php жрет память вагонами и греет процессор. Триггеры - хорошо, но пока нарисуешь что-то сложнее ой, у нас тут 0 вместо 1 - упаришься. Невозможность опросить итем по срабатыванию триггера это вобще 10+. Из-за этой мелочи приходиться хранить данные переодического опроса (хотя они не нужны и не менялись с предыдущей перезагрузки железа). Да, триггеры слабоваты, не гибкие. Процесс апгрейда - занимательная песня, его просто нет. Проще выкинуть всё, что было и нарисовать с нуля но на новой версии. Есть SQL скрипт, позволяющий перейти на версию 2 с версии 1. Если бы я его не пробовал применить - я бы не говорил, что оно наполовину рабочее. Что не сконвертировалось? Сконевертировалось всё, вот только макросы не добавились для LLD. А так - почти работало. Я вскоре собираюсь ставить 2-й и перенести конфигурацию с тестового 1.8. На данный момент, всё-таки ограничусь Zabbix. Поищу патч от Яндекс. Если найду - хорошо. В любом случае, пока что, не очень критично. Не найдешь ты их. Есть у меня предположение, что там от забикса только название осталось. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator of POST Ltd. mailto:temn...@kmv.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pf1u2a-473@kenga.kmv.ru
Re: Виртуализация
03.04.2013 07:24, Stanislav Vlasov пишет: Кстати, потому хотелось бы, чтобы кластер был виден, как одна машина, с одним IP: экран на виртуалке и проброс портов на внутренние виртуалки. Э... Накой, собственно, один ип на всё? Можно и так, конечно. Но смысл в локалке-то? Там адреса не ограничены. Смысл в том, чтобы внутри локалки кластер был виден, как одна машина и не возникало лишних вопросов. 3 - может быть clvm (clustered lvm). Возможно, будет на несколько процентов быстрее. В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM? Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт поверх. Просто это lvm, работающий в кластере, когда тома лвм доступны всем узлам кластера. А управление блокировками на файлы/участки файлов чем реализуется? Там нет файлов, это LVM. Блокировки - через кластерную инфраструктуру типа corosync или что-то подобное. Я понял, потому и спрашиваю, должна ли поверх cLVM быть кластерная ФС? Завтра про него почитаю, если найду время. Насчёт corosync, я понял, что это слой сообщений... Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на один сервер - не подойдёт. В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в пределе. iscsi на этом же стенде упёрся в диски по iops. Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в сеть), так что тут разночтений нет. Всё ясно. DRDB+iSCSI и не мудрить. Ну да, если на сторадже не будет виртуалок. Думаю, не будет. С другой стороны, я ведь могу использовать паравиртуализованные ОС без потери производительности? Как обычно, вобщем-то. Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP Proliant)? Только для линуксов. Хм... А гипервизор только Xen? Помнится, на старых компах, на которых собирался поднимать виртуалки, нет аппаратной виртуализации. Так что - таки да, только Xen. Можно lxc или openvz, но там уже не совсем виртуалки. Кстати, да... Стоит подумать об OpenVZ, который, к тому же, здесь уже хвалили. Довели, наверное... Для чего тогда была новость, если в публичном доступе этого нет? Судя по той ссылке - это было приглашение на работу программиста, который должен будет переделывать заббикс. Мне показалось, что это презентация системы. :-) Ещё PDF-ка с похожим содержанием где-то валялась. Типа этого: http://download.yandex.ru/company/experience/rit2008/highload_lapan.pdf Хм... Значит, ту ссылку я пропустил. Тем не менее, в публичном доступе нет - воспользоваться нельзя. Разве что уговорить продать. :-) Особенно, учитывая то, что кроме меня, это никому не нужно. 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные бэкапы таким образом (напрямую на сервер). Не совсем понял вопроса. Накой делать копии сервера на сам сервер? Инкрементальную копию удалённой машины на сервер. Возможно? Или нет? Или не стоит? Гм... rsnapshot - средство создания копии дерева каталогов. Организация хранения дерева каталогов такова, что можно увидеть копии дерева на предыдущие моменты времени. А то, как именно сделано копирование - уже другой вопрос. Так тот же самый, с точки зрения преимуществ перед другими системами. Хм... man rsync. Почти 2000 строчек наводят уныние... :-) Это разве много? :-) С учётом того, что сейчас у меня снова поломался rdiff-backup, я уже сомневаюсь. :-| И пришлось полностью удалить бэкап. Мало того, виртуалки не бэкапятся, потому что долго и места много. У rsnapshot можно и опции позадавать, хотя и по-умолчанию будет копироваться только изменившееся. Не помню, правда, будут ли по-умолчанию считаться контрольные суммы остальных файлов или всё по размеру/времени изменения определяется. Будет копироваться изменившийся файл, а не участок, так? Не помню, как оно по-умолчанию. С опцией -c по сети однозначно будут передаваться только изменившиеся блоки. Он по CRC сверяет? Видимо, потому, что на предыдущей работе до покупки бекапа от Symantec было довольно серьёзное рассмотрение доступных систем бекапов и аманда таки шла наравне с симантеком, который выиграл только из-за требований от стороннего софта про что-то там сертифицированное. К сожалению, не помню, чем там не понравилась бакула, это было почти три года назад. Но осадочек остался :-) А чем понравилась Amanda? Хотелось бы чуть подробнее? А недостатки? Э... http://www.percona.com/software/percona-xtrabackup Еще раз табличку пересмотрите. Там разницы -
Re: Виртуализация
2 апреля 2013 г., 23:27 пользователь Артём Н. artio...@yandex.ruнаписал: 02.04.2013 08:13, Stanislav Vlasov пишет: 4. Коммутатор (говорят, что возможно найти лишний). Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. Хм... Разве что сумеете обеспечить связь каждый с каждым без него, причём с двойным резервированием. Мда, проще найти коммутатор. Просто раньше они, говорят, валялись кучкой, а сейчас найти не получается. shop.nag.ru в помощь. Правда, не знаю, насколько быстро. Мда... Так а что делать? Там кластера особо никто не ждёт. Даже наоборот. Нужны бэкапы и мониторилка (двух машин, которые под это выделили, достаточно за глаза). Кластер я для себя хочу, ради обучения. И мне даже плюс, что ресурс сильно ограничен, - думать заставляет и выбирать. Кстати, потому хотелось бы, чтобы кластер был виден, как одна машина, с одним IP: экран на виртуалке и проброс портов на внутренние виртуалки. Э... Накой, собственно, один ип на всё? Можно и так, конечно. Но смысл в локалке-то? Там адреса не ограничены. Я могу убрать два диска из Lustre и создать из них DRBD? Можно и так. Но опять же - в оффлайне. Т.е., убрать с них данные (без особых мучений, естественно), перекинув на остальные. Затем, убрать из LustreFS. После чего сделать из них том DRDB. Ну да, вывести из эксплуатации и делать что хошь. 3 - может быть clvm (clustered lvm). Возможно, будет на несколько процентов быстрее. В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM? Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт поверх. Просто это lvm, работающий в кластере, когда тома лвм доступны всем узлам кластера. А управление блокировками на файлы/участки файлов чем реализуется? Там нет файлов, это LVM. Блокировки - через кластерную инфраструктуру типа corosync или что-то подобное. AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом плане менее капризен. Какие проблемы? При бондинге двух сетевых карт и на клиенте и на сервере скрость передачи упёрлась в одну сетевую карту. В смысле? Не очень понял. Работали обе сетевые карты, но максимальная скорость каждой была ограничена скоростью самой низкоскоростной? Там были две по гигабиту. Пробовались два варианта - только средствами AoE и бондинг. В обоих случаях получался гигабит максимум. Дальше не разбирались. Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на один сервер - не подойдёт. В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в пределе. iscsi на этом же стенде упёрся в диски по iops. Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в сеть), так что тут разночтений нет. Всё ясно. DRDB+iSCSI и не мудрить. Ну да, если на сторадже не будет виртуалок. С другой стороны, я ведь могу использовать паравиртуализованные ОС без потери производительности? Как обычно, вобщем-то. Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP Proliant)? Только для линуксов. Хм... А гипервизор только Xen? Помнится, на старых компах, на которых собирался поднимать виртуалки, нет аппаратной виртуализации. Так что - таки да, только Xen. Можно lxc или openvz, но там уже не совсем виртуалки. Довели, наверное... Для чего тогда была новость, если в публичном доступе этого нет? Судя по той ссылке - это было приглашение на работу программиста, который должен будет переделывать заббикс. Мне показалось, что это презентация системы. :-) Ещё PDF-ка с похожим содержанием где-то валялась. Типа этого: http://download.yandex.ru/company/experience/rit2008/highload_lapan.pdf Хм... Значит, ту ссылку я пропустил. Тем не менее, в публичном доступе нет - воспользоваться нельзя. Разве что уговорить продать. 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные бэкапы таким образом (напрямую на сервер). Не совсем понял вопроса. Накой делать копии сервера на сам сервер? Инкрементальную копию удалённой машины на сервер. Возможно? Или нет? Или не стоит? Гм... rsnapshot - средство создания копии дерева каталогов. Организация хранения дерева каталогов такова, что можно увидеть копии дерева на предыдущие моменты времени. А то, как именно сделано копирование - уже другой вопрос. Так тот же самый, с точки зрения преимуществ перед другими системами. Хм... man rsync. Почти 2000 строчек наводят уныние... :-) Это разве много? :-) У rsnapshot можно и опции позадавать, хотя и по-умолчанию будет копироваться только изменившееся. Не помню, правда, будут ли по-умолчанию считаться контрольные суммы остальных файлов
Re: Виртуализация
01.04.2013 08:30, Stanislav Vlasov пишет: Очень большое количество компонентов, требуемых для GFS2, взаимосвязь которых хреново настраивается. Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер менее, чем на три машины делать уже точно не стоит. Понятно. Значит, стоит остановиться на OCFS2. Так, насчёт СХД, первый вопрос. Что имею: 1. Два сервера. В каждом 6 SATA на 1 Тб. 2. В них Core2 с Vt-d. 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо запускать). Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе. 2 сервера в каждом 6 x 1 Тб SATA. CPU с Vt-x (VT-d нет, сегодня смотрел). В них 3 сетевых интерфейса. На них сейчас Fedora. Их под СХД. Помимо них, есть старые одноюнитовые HP ProLiant 2006 года с двумя сказями в 70 с чем-то Гб каждый. Сейчас на них RHEL. Они когда-то были резервом, но сейчас настройки прикладного ПО на них неактуальны (как и железо). Это из того, что есть в стойке. На них, естественно, VT нет. Там по два старых ксеона на каждом. Также, валяется ещё один HP с б`ольшим количеством SCSI дисков (но тоже маленьких, наверное до 1 Тб, в сумме, не дотянет). Коммутатор, пока что, найти не удалось. Хотя, если имелось ввиду, что много дисков должно быть на тех же серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки немного подумать над реорганизацией. Бекапы должны лежать отдельно от рабочих серверов. Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех, что под бэкапы (2 старых Xeon против Core2 Duo). Желательно даже на расстоянии и в сейфе. Увы, нереально (реально разнести их по разным серверным, но слишком проблематично). Они стоят в соседних стойках. Но, физическое разделение, в принципе, не ко мне. К тому же, при создании бекапов будет довольно приличная дисковая нагрузка, процессор будет в основном в состоянии iowait, что повлияет на работу виртуалок. Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно? 4. Коммутатор (говорят, что возможно найти лишний). Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. Что требуется: 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно ограничиться только настройками (думаю, что систему там смогут поставить). Под это вполне хватит 8 Тб. 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза хватит 2 Тб. Нормальное ТЗ, вобщем-то. К бекапам еще бы ленточек... Георгиевских или вы про стриммеры? :-) Что хочу: 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для образов ВМ. DRBD поверх раздела в 2Тб. Как вариант - сделать этот раздел на стареньких серверах, объединить их в DRBD и потом отдавать по iscsi весь том на оба сервера виртуализации с одного из серверов. На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что сейчас, вообще 100 с чем-то Гб). При отказе - воспользоваться heartbeat для переключения ip-адреса iscsi и master-slave в drbd. 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных копий и базы данных (в т.ч. Zabbix). 3. Иметь возможность менять конфигурацию СХД на лету (например, убрать часть дисков из ненадёжного хранилища и создать ещё одно надёжное). С DRBD настолько на лету не выйдет, проверено. Только переконфигурация томов, созданных поверх DRBD. А с Lustre? Я могу убрать два диска из Lustre и создать из них DRBD? Как хочу реализовать (пока только задумки): I. Надёжное хранилище. 1. Выделить 2 диска на каждом сервере под RAID-0. 2. Объединить в RAID-1, используя DRDB. 3. ФС - OCFS2. 3 - может быть clvm (clustered lvm). Возможно, будет на несколько процентов быстрее. В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM? II. Ненадёжное хранилище. Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше AoE. Либо использовать, например, Lustre. AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом плане менее капризен. Какие проблемы? Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. Вай? По-идее, под бэкапы и хочу. Но почему не под рабочий раздел? Если бы оставить только LustreFS, конфигурация бы сильно упростилась... А стоит ли вообще выдумывать со всякими надёжными-ненадёжным хранилищами? Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь ей не нужен DRBD? Не нужен, но по iops оно значительно медленнее, чем iscsi. Т.е., для виртуалок не подойдёт..? Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет пропадать впустую. А с какой целью оно надо? Что на локальном разделе, что на удалённом - монопольно пробросить аппаратный диск не выйдет, если его специально не выделяли для виртуалки. Устройство PCI - выйдет при
Re: Виртуализация
2 апреля 2013 г., 0:36 пользователь Артём Н. artio...@yandex.ru написал: 01.04.2013 08:30, Stanislav Vlasov пишет: Очень большое количество компонентов, требуемых для GFS2, взаимосвязь которых хреново настраивается. Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер менее, чем на три машины делать уже точно не стоит. Понятно. Значит, стоит остановиться на OCFS2. Это проще. Хотя, если имелось ввиду, что много дисков должно быть на тех же серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки немного подумать над реорганизацией. Бекапы должны лежать отдельно от рабочих серверов. Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех, что под бэкапы (2 старых Xeon против Core2 Duo). Мда... К тому же, при создании бекапов будет довольно приличная дисковая нагрузка, процессор будет в основном в состоянии iowait, что повлияет на работу виртуалок. Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно? А это неважно. Время случайного доступа никто не отменял. 4. Коммутатор (говорят, что возможно найти лишний). Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. Хм... Разве что сумеете обеспечить связь каждый с каждым без него, причём с двойным резервированием. Что требуется: 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно ограничиться только настройками (думаю, что систему там смогут поставить). Под это вполне хватит 8 Тб. 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза хватит 2 Тб. Нормальное ТЗ, вобщем-то. К бекапам еще бы ленточек... Георгиевских или вы про стриммеры? :-) Таки про стримеры. С одной м :-) Что хочу: 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для образов ВМ. DRBD поверх раздела в 2Тб. Как вариант - сделать этот раздел на стареньких серверах, объединить их в DRBD и потом отдавать по iscsi весь том на оба сервера виртуализации с одного из серверов. На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что сейчас, вообще 100 с чем-то Гб). Мда... Извращение... 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных копий и базы данных (в т.ч. Zabbix). 3. Иметь возможность менять конфигурацию СХД на лету (например, убрать часть дисков из ненадёжного хранилища и создать ещё одно надёжное). С DRBD настолько на лету не выйдет, проверено. Только переконфигурация томов, созданных поверх DRBD. А с Lustre? Я могу убрать два диска из Lustre и создать из них DRBD? Можно и так. Но опять же - в оффлайне. Как хочу реализовать (пока только задумки): I. Надёжное хранилище. 1. Выделить 2 диска на каждом сервере под RAID-0. 2. Объединить в RAID-1, используя DRDB. 3. ФС - OCFS2. 3 - может быть clvm (clustered lvm). Возможно, будет на несколько процентов быстрее. В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM? Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт поверх. Просто это lvm, работающий в кластере, когда тома лвм доступны всем узлам кластера. II. Ненадёжное хранилище. Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше AoE. Либо использовать, например, Lustre. AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом плане менее капризен. Какие проблемы? При бондинге двух сетевых карт и на клиенте и на сервере скрость передачи упёрлась в одну сетевую карту. Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. Вай? По-идее, под бэкапы и хочу. Но почему не под рабочий раздел? Если бы оставить только LustreFS, конфигурация бы сильно упростилась... iops. Виртуалки тоже хотят писать на диск, причём часто. А стоит ли вообще выдумывать со всякими надёжными-ненадёжным хранилищами? Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь ей не нужен DRBD? Не нужен, но по iops оно значительно медленнее, чем iscsi. Т.е., для виртуалок не подойдёт..? Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на один сервер - не подойдёт. В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в пределе. iscsi на этом же стенде упёрся в диски по iops. Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в сеть), так что тут разночтений нет. С другой стороны, я ведь могу использовать паравиртуализованные ОС без потери производительности? Как обычно, вобщем-то. Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP Proliant)? Только для линуксов. Ну я понял, что БД, всё-таки - крайне узкое место. Но, насколько я понял, проблема с ней уже была решена Яндексом. Вначале рекомендую найти это решение. Лично я пока что видел только
Re: Виртуализация
29.03.2013 00:48, Eugene Berdnikov пишет: On Thu, Mar 28, 2013 at 09:40:41PM +0400, Артём Н. wrote: 26.03.2013 18:42, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. You could say: localtime() is not a reentrant function. Right. But why does it hang ? Let???s look into libc source code. On our Debian GNU/Linux 6.0 machine the interesting part is in eglibc-2.11.3/time/localtime.c И что тут смешного? Со всеми бывает. Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает снятия блокировки прерванного localtime(). Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была рассчитана на многопоточность, а разработчики предпочитали отделываться добавлением костылей. Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, объясните? Я не в теме. Да, совершенно не в теме. :) Вы даже не прочли внимательно этот триллер, а ведь его авторы, хоть и чайники в сигналах, всё-таки отличают проблемы многопоточности и синхронизации от проблем обработки прерываний. Oни там пишут, что замена localtime() на localtime_r() не поможет, и это верно: в обработчике сигнала бесполезно ждать снятия блокировки, если блокировка наложена вне контекста прерывания. В тот контекст можно лишь вернуться, дождаться же невозможно. Sorry. Перечитал. But Zabbix on UNIX/Linux is not multithreaded. It is multi-process. The process hang occurs when a process execution flow is interrupted by it’s own signal handler and the localtime() is used in both at the same time. So, replacing localtime() with localtime_r() will not solve the problem. Что предлагают авторы в качестве лечения -- кому смешно, а кому грустно... Они героически придумывают как уменьшить вероятность дедлока, вместо того, чтобы устранить его вообще. Но... У них же есть The right solution. :-) Только, Unfortunately, the list of asynchronous-signal-safe functions does not include many popular functions, even printf() is not safe. Obviously, localtime() is not in the list either. Похоже, их не посетила мысль, что в обработчике недопустимо что-либо логгировать и приступать к сворачиванию работы -- ведь какая-то операция была прервана, сперва нужно её завершить. Иначе нет гарантии, что не будут повреждены какие-то недописанные данные. Попытка позвать логгер из обработчика может разнести всё к чёртовой матери, а может вызвать повисание... например, из-за неявного вызова того же localtime(). Но они пишут про то, что обработчик большой и переписывать долго... К тому же, что делать, если *надо* логгировать? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51581080.7080...@yandex.ru
Re: Виртуализация
29.03.2013 09:31, Stanislav Vlasov пишет: 29 марта 2013 г., 0:03 пользователь Артём Н. artio...@yandex.ru написал: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Например? Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси. Но дорого. Да не. Аппаратные системы от HP мне никто не отдаст. :-) Из программного: только DRDB+OCFS? Да. Наблюдаю удачное применение DRBD, но делал не я, так что про грабли рассказать не могу. OCFS можно заменить на GFS, но геморрою при этом будет значительно больше, если не RHEL. RHEL/CentOS - сами по себе сплошные проблемы. Да и в RHEL тоже геморрой по сравнению с OCFS. В чём? Так, насчёт СХД, первый вопрос. Что имею: 1. Два сервера. В каждом 6 SATA на 1 Тб. 2. В них Core2 с Vt-d. 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо запускать). 4. Коммутатор (говорят, что возможно найти лишний). Что требуется: 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно ограничиться только настройками (думаю, что систему там смогут поставить). Под это вполне хватит 8 Тб. 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза хватит 2 Тб. Что хочу: 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для образов ВМ. 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных копий и базы данных (в т.ч. Zabbix). 3. Иметь возможность менять конфигурацию СХД на лету (например, убрать часть дисков из ненадёжного хранилища и создать ещё одно надёжное). Как хочу реализовать (пока только задумки): I. Надёжное хранилище. 1. Выделить 2 диска на каждом сервере под RAID-0. 2. Объединить в RAID-1, используя DRDB. 3. ФС - OCFS2. II. Ненадёжное хранилище. Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше AoE. Либо использовать, например, Lustre. А стоит ли вообще выдумывать со всякими надёжными-ненадёжным хранилищами? Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь ей не нужен DRBD? Я про неё, пока что, только начал читать. Может, ей возможно явно указать, данные, которые требуют репликации и которые не требуют вовсе, например (ы, и где реплицировать, a-la Spanner от google :-) )? Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет пропадать впустую. С другой стороны, я ведь могу использовать паравиртуализованные ОС без потери производительности? И ведение чёрного ящика. Хм... Что имелось ввиду Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить параметры, которые могут навести на причину проблем. Параметры в каком виде? Графики - обычно только показывают, когда стряслось. Не только. Возможно посмотреть что было перед этим (например, кратковременно пропадала связь или увеличилось количество ошибок интерфейса), а также на графиках удобно наблюдать корреляции между разными переменными (те же пинги и загрузка системы, к примеру). чем недостаточен для этого удалённый сислог? 1. В Windows нет syslog. С виндами, конечно, хуже. Для них - отдельные средства. Только агент и остаётся. Через винды нужно мониторить машины с QNX. К тому же, там уже всё настроено (правда, чтобы всё нормально работало, для этой замечательной системы пришлось написать свою утилиту ping :-) ). 2. Syslog надо чем-то анализировать. Придётся думать, чем строить графики. Э... Пока что по сислогу графиков не строил, чисто текстовыми средствами анализировал. Я образно. :-) Logcheck и товарищей тоже надо настраивать на нестандартные события. 3. Syslog не записывает столько информации, сколько агент. Конечно, возможно запустить разную мониторинговую приблуду, которая будет всё валить в лог, но это будет не очень удобно. Гораздо проще и эффективнее иметь единый агент. Не факт, что эффективнее... Впрочем, всякий SNMP никто не отменял. Так одно другому не мешает. По SNMP собирались мониторить APC-шные ИБП. Через Zabbix. Вроде даже адаптеры закупили, которые состояние ИБП через SNMP сливают. Правда я только один адаптер видел. :-) У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по количеству запросов в секунду и стала мешать соседям. Были установлены нагиос и какти, были натравлены на те же показатели, нагрузка стала на порядок меньше. Ну я понял, что БД, всё-таки - крайне узкое место. Но, насколько я понял, проблема с ней уже была решена Яндексом. Вначале рекомендую найти это решение. Лично я пока что видел только сообщение о его поиске. Пока что, никаких результатов. Либо они его не предоставляли в общее пользование, либо я плохо искал. К тому же, далеко не факт, что замена БД на фс уменьшит нагрузку. Думаю, что уменьшит. Ещё
Re: Виртуализация
On Sun, Mar 31, 2013 at 02:31:28PM +0400, Артём Н. wrote: 29.03.2013 00:48, Eugene Berdnikov пишет: Что предлагают авторы в качестве лечения -- кому смешно, а кому грустно... Они героически придумывают как уменьшить вероятность дедлока, вместо того, чтобы устранить его вообще. Но... У них же есть The right solution. :-) У них оно right потому что единственное, т.е. ничего слаще редьки не знают... Только, Unfortunately, the list of asynchronous-signal-safe functions does not include many popular functions, even printf() is not safe. Obviously, localtime() is not in the list either. Похоже, их не посетила мысль, что в обработчике недопустимо что-либо логгировать и приступать к сворачиванию работы -- ведь какая-то операция была прервана, сперва нужно её завершить. Иначе нет гарантии, что не будут повреждены какие-то недописанные данные. Попытка позвать логгер из обработчика может разнести всё к чёртовой матери, а может вызвать повисание... например, из-за неявного вызова того же localtime(). Но они пишут про то, что обработчик большой и переписывать долго... К тому же, что делать, если *надо* логгировать? Нужно учить матчасть, натурально. В интернете, уверен, есть полно ресурсов, где написано как правильно работать с сигналами. На русском языке в группе фидо ru.unix.prog регулярно постилось мини-хауту (не знаю, как там сейчас). Можно правильно логгировать даже из-под обработчика, хотя это требует некоторых нетривиальных приёмов, но их можно выучить. Но это всё весьма далеко от тематики debian-russian, поэтому развивать тему не буду... Что касается пользователей zabbix, видимо, им нужно возводить стройные системы костылей и подпорок по мере роста масштабов сервиса. :) Ничего, сисадминам приходится так поступать с практически любым продуктом, как свободным, так и коммерческим. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130331133056.gb3...@sie.protva.ru
Re: Виртуализация
31 марта 2013 г., 18:01 пользователь Артём Н. artio...@yandex.ru написал: Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси. Да не. Аппаратные системы от HP мне никто не отдаст. :-) Из программного: только DRDB+OCFS? Да. Наблюдаю удачное применение DRBD, но делал не я, так что про грабли рассказать не могу. OCFS можно заменить на GFS, но геморрою при этом будет значительно больше, если не RHEL. RHEL/CentOS - сами по себе сплошные проблемы. Не совсем. Пока задачи не выходят за рамки того, что есть в основном репозитории - отличное решение, причём очень даже работающее. А вот чуть в сторону - таки геморрой. Да и в RHEL тоже геморрой по сравнению с OCFS. В чём? Очень большое количество компонентов, требуемых для GFS2, взаимосвязь которых хреново настраивается. Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер менее, чем на три машины делать уже точно не стоит. Так, насчёт СХД, первый вопрос. Что имею: 1. Два сервера. В каждом 6 SATA на 1 Тб. 2. В них Core2 с Vt-d. 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо запускать). Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе. Хотя, если имелось ввиду, что много дисков должно быть на тех же серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки немного подумать над реорганизацией. Бекапы должны лежать отдельно от рабочих серверов. Желательно даже на расстоянии и в сейфе. К тому же, при создании бекапов будет довольно приличная дисковая нагрузка, процессор будет в основном в состоянии iowait, что повлияет на работу виртуалок. 4. Коммутатор (говорят, что возможно найти лишний). Для надёжности лучше два. Что требуется: 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно ограничиться только настройками (думаю, что систему там смогут поставить). Под это вполне хватит 8 Тб. 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза хватит 2 Тб. Нормальное ТЗ, вобщем-то. К бекапам еще бы ленточек... Что хочу: 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для образов ВМ. DRBD поверх раздела в 2Тб. Как вариант - сделать этот раздел на стареньких серверах, объединить их в DRBD и потом отдавать по iscsi весь том на оба сервера виртуализации с одного из серверов. При отказе - воспользоваться heartbeat для переключения ip-адреса iscsi и master-slave в drbd. 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных копий и базы данных (в т.ч. Zabbix). 3. Иметь возможность менять конфигурацию СХД на лету (например, убрать часть дисков из ненадёжного хранилища и создать ещё одно надёжное). С DRBD настолько на лету не выйдет, проверено. Только переконфигурация томов, созданных поверх DRBD. Как хочу реализовать (пока только задумки): I. Надёжное хранилище. 1. Выделить 2 диска на каждом сервере под RAID-0. 2. Объединить в RAID-1, используя DRDB. 3. ФС - OCFS2. 3 - может быть clvm (clustered lvm). Возможно, будет на несколько процентов быстрее. II. Ненадёжное хранилище. Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше AoE. Либо использовать, например, Lustre. AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом плане менее капризен. Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. А стоит ли вообще выдумывать со всякими надёжными-ненадёжным хранилищами? Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь ей не нужен DRBD? Не нужен, но по iops оно значительно медленнее, чем iscsi. Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет пропадать впустую. А с какой целью оно надо? Что на локальном разделе, что на удалённом - монопольно пробросить аппаратный диск не выйдет, если его специально не выделяли для виртуалки. Устройство PCI - выйдет при любом диске, но при этом не получится мигрировать виртуалку, в которую пробросил. С другой стороны, я ведь могу использовать паравиртуализованные ОС без потери производительности? Как обычно, вобщем-то. Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить параметры, которые могут навести на причину проблем. Параметры в каком виде? Графики - обычно только показывают, когда стряслось. Не только. Возможно посмотреть что было перед этим (например, кратковременно пропадала связь или увеличилось количество ошибок интерфейса), а также на графиках удобно наблюдать корреляции между разными переменными (те же пинги и загрузка системы, к примеру). И? Причём тут именно заббикс? чем недостаточен для этого удалённый сислог? 1. В Windows нет syslog. С виндами, конечно, хуже. Для них - отдельные средства. Только агент и остаётся. Через винды нужно мониторить
Re: Виртуализация
22.03.2013 11:50, Maksym Tiurin пишет: Артём Н. writes: 16.03.2013 21:52, Maksym Tiurin пишет: Артём Н. writes: Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. А что происходит, при количестве хостов в несколько тысяч? Все хранится в одной RDBMS. ИМХО идею здравой назвать нельзя. Хм... Но ведь MySQL используется многими компаниями? Говорят, что тот же google её использует... Для хранения статистики? Не используют конечно. Да и мускуль там специфический. Ага, я почитал про них. MySQL если используется, то для каких-то узких задач. А так у них всё своё... И лучше ли масштабируемость у Nagios? В случае Nagios+конфиг-генератор маштабируемость лучше. Кроме того Nagios уже используется в больших конторах. И по граблам там уже прошлись первопроходцы. 1. Что за конфиг-генератор? http://exchange.nagios.org/directory/Addons/Configuration 2. А Zabbix, разве нет? Ведь он анонсирован, как система уровня предприятия... Предприятия бывают и вообще без компов :) Хм... Я сомневаюсь, что сейчас возможно найти даже среднее предприятие без компов. А Zabbix всё же не настолько плох, как вы его малюете. :-) Да и Nagios далеко не идеален (особого впечатления он не произвёл): http://webcrunch.ru/library/administration/support/yandex-monitoring/ Честно, вначале я совсем немного смотрел Nagios, но он мне не понравился. На вики написано: Распределенный мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящихся на более высоком уровне иерархии. И вся эта толпа гадит в одну DB :) Для СУБД это очень большая нагрузка или всё-таки не запредельная? Какие требуются минимальные ресурсы по памяти и CPU для 1000 хостов? Эта нагрузка конечно не запредельная. Но это узкое место и использование СУБД общего назначения для такой задачи вызывает две проблемы 1) база растет как на дрожжах, при росте падает быстродействие 2) базу надо чистить от старых записей и эта операция достаточно сильно грузит сервер Короче, буду смотреть в сторону Системы мониторинга Yandex. Мне гораздо любопытнее сейчас разобраться с кластером, которым я собираюсь заняться со следующей недели. В частности и во-первых с СХД. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51547d20.6040...@yandex.ru
Re: Виртуализация
26.03.2013 18:42, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. You could say: localtime() is not a reentrant function. Right. But why does it hang ? Let’s look into libc source code. On our Debian GNU/Linux 6.0 machine the interesting part is in eglibc-2.11.3/time/localtime.c И что тут смешного? Со всеми бывает. Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает снятия блокировки прерванного localtime(). Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была рассчитана на многопоточность, а разработчики предпочитали отделываться добавлением костылей. Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, объясните? Я не в теме. Жабикс крив по своей внутренней идеологии и организации. Унутре оно всё однопоточное, из-за этого обвешано нелепыми таймаутами. Импорт хостов с темплейтами может занимать несколько часов, при этом только php жрет память вагонами и греет процессор. Триггеры - хорошо, но пока нарисуешь что-то сложнее ой, у нас тут 0 вместо 1 - упаришься. Невозможность опросить итем по срабатыванию триггера это вобще 10+. Из-за этой мелочи приходиться хранить данные переодического опроса (хотя они не нужны и не менялись с предыдущей перезагрузки железа). Да, триггеры слабоваты, не гибкие. Процесс апгрейда - занимательная песня, его просто нет. Проще выкинуть всё, что было и нарисовать с нуля но на новой версии. Есть SQL скрипт, позволяющий перейти на версию 2 с версии 1. Если бы я его не пробовал применить - я бы не говорил, что оно наполовину рабочее. Что не сконвертировалось? Я вскоре собираюсь ставить 2-й и перенести конфигурацию с тестового 1.8. На данный момент, всё-таки ограничусь Zabbix. Поищу патч от Яндекс. Если найду - хорошо. В любом случае, пока что, не очень критично. Документация невнятная, типичный use case проще найти в форуме, чем в ней. Кстати, документация ещё более ли менее. Документация - возможно, но use case этих наворотов прийдется выяснять самому. Только вот смоделировать срабатывание триггера через конструктор очень тяжко. Да, найди мне в документации - как использовать zabbix_sender с рабочим примером. https://www.zabbix.com/documentation/ru/1.8/manpages/zabbix_sender с *рабочим* примером Рабочесть не проверял, т.к. здесь Zabbix у меня нет и ставить лень. Web-морда? Верх безумия. Посмотреть по быстрому, из-за чего сработал триггер (сами исходные данные) нельзя, надо мышкой повозить, повозить. Комменты к тригерам оператору показать - ни-ни-ни, это секретная информация. Это я еще промолчал как конфигурить zabbix_server и mysql под него. А в чём там проблема? Тут уже писали - объемы ненужных данных таки, что база данных засирается с огромной скоростью. И тут-же начинаем плясать вокруг партиционирования, ручных покручиваний запуска всяких Start* в zabbix_server.conf. Вот хороший мессадж про тонкую настройку машин под него: http://sourceforge.net/mailarchive/message.php?msg_id=30638688 судя по настройкам - памяти у него гигов по 48 на ноду, mysql испытывает проблемы с скоростью записи на диск. Ну понял. Буду искать патч. Еще вопросы будут? Какую бы систему вы стали использовать, если бы у вас была возможность всё с нуля сделать? Помимо Nagios? Каждую систему надо ставить и смотреть, что она умеет. у меня начальственная прихоть грызть это. А, если по вашему предшествующему опыту и по вашему желанию? И ещё, к основному вопросу: а что насчёт OpenNebula? На рубях написанная настдстройка к libvirt? Мне без надобности, не смотрел. А OpenStack? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51548099.7010...@yandex.ru
Re: Виртуализация
22.03.2013 11:56, Dmitry A. Zhiglov пишет: 21 марта 2013 г., 21:03 пользователь Артём Н. artio...@yandex.ru написал: 21.03.2013 20:31, Dmitry A. Zhiglov пишет: Настраивается в /etc/munin/munin.conf #contact.someuser.command mail -s Munin notification someju...@fnord.comm #contact.anotheruser.command mail -s Munin notification anotheru...@blibb.comm Не пользовался этим. Надо бы воспользоваться и кажется, что меня munin устроит =) А штатные средства верещания приятным женским голосом там есть? :-) Вам шашечки или ехать? =) Ехать с шашечками. :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515480c5.8040...@yandex.ru
Re: Виртуализация
22.03.2013 08:30, Stanislav Vlasov пишет: 21 марта 2013 г., 21:12 пользователь Артём Н. artio...@yandex.ru написал: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Например? Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси. Но дорого. Да не. Аппаратные системы от HP мне никто не отдаст. :-) Из программного: только DRDB+OCFS? поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Желательны показометры. На мой взгляд, лучше не смешивать алерты и показометры. Если показометры нужны для начальства - тем более. Для инженеров. И ведение чёрного ящика. Хм... Что имелось ввиду Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить параметры, которые могут навести на причину проблем. чем недостаточен для этого удалённый сислог? 1. В Windows нет syslog. 2. Syslog надо чем-то анализировать. Придётся думать, чем строить графики. 3. Syslog не записывает столько информации, сколько агент. Конечно, возможно запустить разную мониторинговую приблуду, которая будет всё валить в лог, но это будет не очень удобно. Гораздо проще и эффективнее иметь единый агент. А то, что жрёт: на него и кластер. Отдельный кластер для мониторилки - чересчур, по-моему. А если внутри кластера - получится, что под мониторилку выделены ресурсы, которых может не хватить для основных задач. Внутри кластера. Но отдельная ВМ. У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по количеству запросов в секунду и стала мешать соседям. Были установлены нагиос и какти, были натравлены на те же показатели, нагрузка стала на порядок меньше. Ну я понял, что БД, всё-таки - крайне узкое место. Но, насколько я понял, проблема с ней уже была решена Яндексом. Ещё хочу систему рез. копирования. Какую порекомендуете? Сильно зависит от того, как и что хотите копировать. Для файлов из линукса - rsnapshot неплох. У почтового сервера объём бекапа с историей за две недели составлял примерно 1.3 объёма от самого сервера. Да и у остальных серверов примерно также, так как менялись далеко не все файлы. 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие ссылки (да, в NTFS тоже есть, но как-то не хочется). 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные бэкапы таким образом (напрямую на сервер). Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне кажется, плохо подойдёт. Делал снапшоты LVM и копировал диски целиком. Не вариант. В сети есть Windows машины, которые крайне желательно сохранять, причём это отдельные физические сервера, которые нельзя трогать (в плане, как были физическими, так и останутся). Кое-где завалялось малость BSD и немало QNX от 4.25 до 6.x. Хотя, видимо, их сохранять не надо, поскольку особо там ничего не изменяется, да и сохранять их лучше локально (чтобы не иметь проблем, типа вы туда свой софт поставили, из-за этого у нас вся сеть не работает). Также очень даже неплоха bacula. Я думал как раз её использовать, но недавно написали следующее: Bacula community много чего не умеет, в том числ дедупликацию, а без нее бэкапить виртуалки накладно. Что ещё не умеет? Для БД - лучше что-то специализированное. Например? mysqldump? :-] А Bacula не справится с файлами БД (для mysql, mssql и pervasive sql)? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515485f3.30...@yandex.ru
Re: Виртуализация
On Thu, Mar 28, 2013 at 09:40:41PM +0400, Артём Н. wrote: 26.03.2013 18:42, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. You could say: localtime() is not a reentrant function. Right. But why does it hang ? Let???s look into libc source code. On our Debian GNU/Linux 6.0 machine the interesting part is in eglibc-2.11.3/time/localtime.c И что тут смешного? Со всеми бывает. Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает снятия блокировки прерванного localtime(). Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была рассчитана на многопоточность, а разработчики предпочитали отделываться добавлением костылей. Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, объясните? Я не в теме. Да, совершенно не в теме. :) Вы даже не прочли внимательно этот триллер, а ведь его авторы, хоть и чайники в сигналах, всё-таки отличают проблемы многопоточности и синхронизации от проблем обработки прерываний. Oни там пишут, что замена localtime() на localtime_r() не поможет, и это верно: в обработчике сигнала бесполезно ждать снятия блокировки, если блокировка наложена вне контекста прерывания. В тот контекст можно лишь вернуться, дождаться же невозможно. Что предлагают авторы в качестве лечения -- кому смешно, а кому грустно... Они героически придумывают как уменьшить вероятность дедлока, вместо того, чтобы устранить его вообще. Похоже, их не посетила мысль, что в обработчике недопустимо что-либо логгировать и приступать к сворачиванию работы -- ведь какая-то операция была прервана, сперва нужно её завершить. Иначе нет гарантии, что не будут повреждены какие-то недописанные данные. Попытка позвать логгер из обработчика может разнести всё к чёртовой матери, а может вызвать повисание... например, из-за неявного вызова того же localtime(). -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130328204857.gr23...@sie.protva.ru
Re: Виртуализация
29 марта 2013 г., 0:03 пользователь Артём Н. artio...@yandex.ru написал: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Например? Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси. Но дорого. Да не. Аппаратные системы от HP мне никто не отдаст. :-) Из программного: только DRDB+OCFS? Да. Наблюдаю удачное применение DRBD, но делал не я, так что про грабли рассказать не могу. OCFS можно заменить на GFS, но геморрою при этом будет значительно больше, если не RHEL. Да и в RHEL тоже геморрой по сравнению с OCFS. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Желательны показометры. На мой взгляд, лучше не смешивать алерты и показометры. Если показометры нужны для начальства - тем более. Для инженеров. В зависимости от квалификации инженеров - либо таки заббикс, либо какти. Если требуется, чтобы еще и не сильно жрало - лучше второе. И ведение чёрного ящика. Хм... Что имелось ввиду Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить параметры, которые могут навести на причину проблем. Параметры в каком виде? Графики - обычно только показывают, когда стряслось. чем недостаточен для этого удалённый сислог? 1. В Windows нет syslog. С виндами, конечно, хуже. Для них - отдельные средства. 2. Syslog надо чем-то анализировать. Придётся думать, чем строить графики. Э... Пока что по сислогу графиков не строил, чисто текстовыми средствами анализировал. 3. Syslog не записывает столько информации, сколько агент. Конечно, возможно запустить разную мониторинговую приблуду, которая будет всё валить в лог, но это будет не очень удобно. Гораздо проще и эффективнее иметь единый агент. Не факт, что эффективнее... Впрочем, всякий SNMP никто не отменял. У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по количеству запросов в секунду и стала мешать соседям. Были установлены нагиос и какти, были натравлены на те же показатели, нагрузка стала на порядок меньше. Ну я понял, что БД, всё-таки - крайне узкое место. Но, насколько я понял, проблема с ней уже была решена Яндексом. Вначале рекомендую найти это решение. Лично я пока что видел только сообщение о его поиске. К тому же, далеко не факт, что замена БД на фс уменьшит нагрузку. Ещё хочу систему рез. копирования. Какую порекомендуете? Сильно зависит от того, как и что хотите копировать. Для файлов из линукса - rsnapshot неплох. У почтового сервера объём бекапа с историей за две недели составлял примерно 1.3 объёма от самого сервера. Да и у остальных серверов примерно также, так как менялись далеко не все файлы. 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие ссылки (да, в NTFS тоже есть, но как-то не хочется). Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - rsync. К тому же, для винды есть виндовые средства, которые лучше спрашивать там, где виндами пользуются больше. Кстати, припоминаю, что amanda умела бекапить винды штатными виндовыми средствами. Возможно, путаю и там требовался бекапный агент, но что умела - точно. 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные бэкапы таким образом (напрямую на сервер). Не совсем понял вопроса. Накой делать копии сервера на сам сервер? Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне кажется, плохо подойдёт. При большой нагрузке на сервер бекапов наблюдал, что база rdiff-backup ломается. Что касается сети - работало нормально. Делал снапшоты LVM и копировал диски целиком. Не вариант. В сети есть Windows машины, которые крайне желательно сохранять, причём это отдельные физические сервера, которые нельзя трогать (в плане, как были физическими, так и останутся). Тогда - ищем виндовые средства. Кое-где завалялось малость BSD и немало QNX от 4.25 до 6.x. Хотя, видимо, их сохранять не надо, поскольку особо там ничего не изменяется, да и сохранять их лучше локально (чтобы не иметь проблем, типа вы туда свой софт поставили, из-за этого у нас вся сеть не работает). Один раз сделать dd диска, сохранить в N мест для надёжности и потом копировать только изменившиеся места Можно через scp, если rsync нельзя ставить. Также очень даже неплоха bacula. Я думал как раз её использовать, но недавно написали следующее: Bacula community много чего не умеет, в том числ дедупликацию, а без нее бэкапить виртуалки накладно. Что ещё не умеет? Кто его знает... Давно ей пользовался... Для БД - лучше что-то специализированное. Например? mysqldump? :-] А Bacula не справится с файлами БД (для mysql, mssql и pervasive sql)?| БД файлами можно бекапить только в выключенном
Re: Виртуализация
Mikhail A Antonov b...@solarnet.ru wrote: [-- text/plain, encoding base64, charset: KOI8-R, 16 lines --] 19.03.2013 21:09, Andrey Melnikoff пишет: Еще вопросы будут? Со всеми вышеперечисленными минусами согласен. Что рекомендуешь использовать вместо заббикса? То, что выросло из nagios'a. можно кактус. Тут уже все, что можно было - насоветовали. Надо: * графики - загрузка интерфейсов(mbits,pps), цпу, диска, памяти, ещё чего придумается * для добавления\редактирования хоста не требовало лезть в конфиги * наглядность событий хост жив, хост сдох, и подобные * учитывать что оператор, реагирующий на триггеры чуть умнее стола * собирать инфу как с snmp, так и с накого-то аналога zabbix-agent * уметь IPv6 * желательно уметь слать алерты на центральный сервер, особо не храня сведений там Заббикс хоть и крив и неудобен местами, но с этими задачами справляется. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator of POST Ltd. mailto:temn...@kmv.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/gag82a-u76@kenga.kmv.ru
Re: Виртуализация
Артём Н. artio...@yandex.ru wrote: 19.03.2013 21:09, Andrey Melnikoff пишет: [skipp] Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Ага, его обмазывают затычками. После скандалы-интриги-расследования (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) тем кто в теме становиться совсем смешно. Жабикс крив по своей внутренней идеологии и организации. Унутре оно всё однопоточное, из-за этого обвешано нелепыми таймаутами. Импорт хостов с темплейтами может занимать несколько часов, при этом только php жрет память вагонами и греет процессор. Триггеры - хорошо, но пока нарисуешь что-то сложнее ой, у нас тут 0 вместо 1 - упаришься. Невозможность опросить итем по срабатыванию триггера это вобще 10+. Из-за этой мелочи приходиться хранить данные переодического опроса (хотя они не нужны и не менялись с предыдущей перезагрузки железа). Да, триггеры слабоваты, не гибкие. Процесс апгрейда - занимательная песня, его просто нет. Проще выкинуть всё, что было и нарисовать с нуля но на новой версии. Есть SQL скрипт, позволяющий перейти на версию 2 с версии 1. Если бы я его не пробовал применить - я бы не говорил, что оно наполовину рабочее. [skip] Обработка состояния итемов? Упал итем в not supported и никак не догадаешься, по какой причине. Запуск внешних скриптов из zabbix_agentd достаточно часто эту проблему вызвает. Хотелось бы конечно понимать почему: таймауты неправильные или ошибка во внешней команде, например... DebugLevel в районе 4 или 5 и расследовать портянки. Иных выходов нет. В каких системах мониторинга указывается причина для not supported? В любых системах это ошибка, которая должна быть видна оператору. А тут предлагается на каждый итем повесить по триггеру с nodata ? Документация невнятная, типичный use case проще найти в форуме, чем в ней. Кстати, документация ещё более ли менее. Документация - возможно, но use case этих наворотов прийдется выяснять самому. Только вот смоделировать срабатывание триггера через конструктор очень тяжко. Да, найди мне в документации - как использовать zabbix_sender с рабочим примером. Web-морда? Верх безумия. Посмотреть по быстрому, из-за чего сработал триггер (сами исходные данные) нельзя, надо мышкой повозить, повозить. Комменты к тригерам оператору показать - ни-ни-ни, это секретная информация. Это я еще промолчал как конфигурить zabbix_server и mysql под него. А в чём там проблема? Тут уже писали - объемы ненужных данных таки, что база данных засирается с огромной скоростью. И тут-же начинаем плясать вокруг партиционирования, ручных покручиваний запуска всяких Start* в zabbix_server.conf. Вот хороший мессадж про тонкую настройку машин под него: http://sourceforge.net/mailarchive/message.php?msg_id=30638688 судя по настройкам - памяти у него гигов по 48 на ноду, mysql испытывает проблемы с скоростью записи на диск. Еще вопросы будут? Какую бы систему вы стали использовать, если бы у вас была возможность всё с нуля сделать? Помимо Nagios? Каждую систему надо ставить и смотреть, что она умеет. у меня начальственная прихоть грызть это. И ещё, к основному вопросу: а что насчёт OpenNebula? На рубях написанная настдстройка к libvirt? Мне без надобности, не смотрел. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator of POST Ltd. mailto:temn...@kmv.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7no82a-ql7@kenga.kmv.ru
Re: Виртуализация
Артём Н. writes: 16.03.2013 21:52, Maksym Tiurin пишет: Артём Н. writes: Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. А что происходит, при количестве хостов в несколько тысяч? Все хранится в одной RDBMS. ИМХО идею здравой назвать нельзя. Хм... Но ведь MySQL используется многими компаниями? Говорят, что тот же google её использует... Для хранения статистики? Не используют конечно. Да и мускуль там специфический. Или по примеру Яндекса патчить Zabbix чтоб выносить статистику из DB на FS. (хотя можно взять Cacti в котором это из коробки :) Хм... Есть публично доступный пропатченный или патчи отдельно? Не интересовался. Про патченье они даже презентацию делали - легко ищется. И лучше ли масштабируемость у Nagios? В случае Nagios+конфиг-генератор маштабируемость лучше. Кроме того Nagios уже используется в больших конторах. И по граблам там уже прошлись первопроходцы. 1. Что за конфиг-генератор? http://exchange.nagios.org/directory/Addons/Configuration 2. А Zabbix, разве нет? Ведь он анонсирован, как система уровня предприятия... Предприятия бывают и вообще без компов :) Честно, вначале я совсем немного смотрел Nagios, но он мне не понравился. На вики написано: Распределенный мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящихся на более высоком уровне иерархии. И вся эта толпа гадит в одну DB :) Для СУБД это очень большая нагрузка или всё-таки не запредельная? Какие требуются минимальные ресурсы по памяти и CPU для 1000 хостов? Эта нагрузка конечно не запредельная. Но это узкое место и использование СУБД общего назначения для такой задачи вызывает две проблемы 1) база растет как на дрожжах, при росте падает быстродействие 2) базу надо чистить от старых записей и эта операция достаточно сильно грузит сервер -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3k3ozvpot@comp.bungarus.info
Re: Виртуализация
21 марта 2013 г., 21:03 пользователь Артём Н. artio...@yandex.ru написал: 21.03.2013 20:31, Dmitry A. Zhiglov пишет: Настраивается в /etc/munin/munin.conf #contact.someuser.command mail -s Munin notification someju...@fnord.comm #contact.anotheruser.command mail -s Munin notification anotheru...@blibb.comm Не пользовался этим. Надо бы воспользоваться и кажется, что меня munin устроит =) А штатные средства верещания приятным женским голосом там есть? :-) Вам шашечки или ехать? =)
Re: Виртуализация
16.03.2013 21:52, Maksym Tiurin пишет: Артём Н. writes: Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. А что происходит, при количестве хостов в несколько тысяч? Все хранится в одной RDBMS. ИМХО идею здравой назвать нельзя. Хм... Но ведь MySQL используется многими компаниями? Говорят, что тот же google её использует... Или по примеру Яндекса патчить Zabbix чтоб выносить статистику из DB на FS. (хотя можно взять Cacti в котором это из коробки :) Хм... Есть публично доступный пропатченный или патчи отдельно? И лучше ли масштабируемость у Nagios? В случае Nagios+конфиг-генератор маштабируемость лучше. Кроме того Nagios уже используется в больших конторах. И по граблам там уже прошлись первопроходцы. 1. Что за конфиг-генератор? 2. А Zabbix, разве нет? Ведь он анонсирован, как система уровня предприятия... Честно, вначале я совсем немного смотрел Nagios, но он мне не понравился. На вики написано: Распределенный мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящихся на более высоком уровне иерархии. И вся эта толпа гадит в одну DB :) Для СУБД это очень большая нагрузка или всё-таки не запредельная? Какие требуются минимальные ресурсы по памяти и CPU для 1000 хостов? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b1e64.9020...@yandex.ru
Re: Виртуализация
19.03.2013 21:09, Andrey Melnikoff пишет: Артём Н. artio...@yandex.ru wrote: 15.03.2013 18:31, Andrey Melnikoff пишет: Stanislav Vlasov stanislav@gmail.com wrote: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. proxmox со своим кластером вроде как умеет, но очень своеобразно. в прошлый раз, когда я трогал кластер из 2х нод - половина виртуалок не поднялась. В чём причина? Не разбирался, сильно было некогда. Что-то там кластер менеджер невнянтное писал про кворум. Да и его собственный автостартер виртуалок иногда творит чудеса. Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно^M получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен tools ему не нужен, оно само себе tools. Но с прициплением сторонних MIB'ов можно поиметь качественного сексу. В плане того, что Zabbix для Федоры (ставил на готовую машину) зависит от snmp-tools, вроде. на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? В последнее время, за что не возьмешься с гордой лейбочкой Enterprise на проверку оказывается дерьмом редкой категории. Да, к слову, попробовал поставить CentOS (он нужен, поскольку всякие old-русские-специалисты, работающие в разных ведомствах, привыкли к rpm-based, который везде пихают, а с учётом того, что денег нет, везде стоит известная всем федора, которая часто падает). Так эта мерзость даже не спросила меня как разбить диск: сделала LVM На свободном разделе, в который запихала один раздел подо всё и swap, а boot сделала отдельно. Отвратительно. Не система, а мерзость. Кучу пакетов потом пришлось ставить через Yum. Не удобно, когда каждый раз приходится набирать yum info, вместо того, чтобы иметь простой curses интерфейс. Так мало того, yum info не работает, когда что-то устанавливается, говоря о том, что блокировку БД пакетов держит кто-то другой. CentOS - клон RHEL. Мне всё-таки до сих пор не верится, что RHEL такое дерьмо. Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не самая плохая система. Жабикс крив по своей внутренней идеологии и организации. Унутре оно всё однопоточное, из-за этого обвешано нелепыми таймаутами. Импорт хостов с темплейтами может занимать несколько часов, при этом только php жрет память вагонами и греет процессор. Триггеры - хорошо, но пока нарисуешь что-то сложнее ой, у нас тут 0 вместо 1 - упаришься. Невозможность опросить итем по срабатыванию триггера это вобще 10+. Из-за этой мелочи приходиться хранить данные переодического опроса (хотя они не нужны и не менялись с предыдущей перезагрузки железа). Да, триггеры слабоваты, не гибкие. Процесс апгрейда - занимательная песня, его просто нет. Проще выкинуть всё, что было и нарисовать с нуля но на новой версии. Есть SQL скрипт, позволяющий перейти на версию 2 с версии 1. Великое достижение LLD в 2.0 работает, но криво. Итемы дисковерятся, графики создаются, но вот отключить опрос созданного таким образом итема или сменить название графика - нельзя. Много даст дежурному инженеру график с названием Traffic on interface Port9: 1000Base-SX/LX ? Из-за этой мелочи - на железку каждого типа приходиться держать 2 темплейта, один с автоматическими графиками, другой без графиков и рисовать их там вручную. Это для 1.8.x и для 2.0.x. Да, графики приходится рисовать вручную, согласен. Но, вообще, я просто перевёл на русский элементы данных в Template:Windows, так что не столь большая проблема. А у нас всего ~600 свичей разных производителей. Бардак в темплейтах - страшный. Исправление триггера для конкретного свича - это песня. Карты? Это смех какой-то а не карты. Автодисковери? Еще тот глюкодром, быстрее написать скрипт с nmap'ом и через апи набить
Re: Виртуализация
19.03.2013 07:25, Роман Гуща пишет: 16.03.2013, 01:47, Артём Н. artio...@yandex.ru: 15.03.2013 18:31, Andrey Melnikoff пишет: Но если автору так хочется жабикс - то использовать dotdeb.org, там он свежий в отличии от стабильного в debian'e. Кстати, за ссылку репозиторий отдельное спасибо. Теперь, думаю, всё на Debian будет. У Zabbix есть свой репозиторий для Debian: https://www.zabbix.com/documentation/2.0/manual/installation/install_from_packages#debian_ubuntu Спасибо. :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b2298.2010...@yandex.ru
Re: Виртуализация
18.03.2013 08:52, Stanislav Vlasov пишет: 15 марта 2013 г., 23:37 пользователь Артём Н. artio...@yandex.ru написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. Я не совсем правильно выразился. Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Например? Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, Хм... Имелся ввиду доступ к хостам через хоста-посредника? Да. Тогда наиболее близкое - nrpe. А помимо Nagios? поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Желательны показометры. И ведение чёрного ящика. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. Вот как раз с ними-то и была проблема - mysql при сборе данных с ~40 хостов по десятке датчиков на хост выжирал весь сервер до такой степени, что вебморда заббикса не каждый раз отображалась. Там, правда, сервер был не самый мощный из доступных и диски sata. Да, возможно, стоило бы потюнить мускль и убрать часть датчиков, но если учесть, что с тех времен стало почти 400 хостов - вряд ли бы заббикс потянул на том железе, что было выделено под nagios+cacti. А то, что жрёт: на него и кластер. Отдельный кластер для мониторилки - чересчур, по-моему. А если внутри кластера - получится, что под мониторилку выделены ресурсы, которых может не хватить для основных задач. Внутри кластера. Но отдельная ВМ. Ещё хочу систему рез. копирования. Какую порекомендуете? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b2379.5050...@yandex.ru
Re: Виртуализация
18.03.2013 11:08, Dmitry A. Zhiglov пишет: 18 марта 2013 г., 8:52 пользователь Stanislav Vlasov stanislav@gmail.com написал: поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Поддерживаю! Здравые аргументы! А если не нужно предупреждений и достаточно статистики для аналитики, то мне нравится munin. Выглядит неплохо. А если нужно и то, и то? Впрочем, сейчас система мониторинга отодвинулась на задний план. Я потому ей займусь. Думаю насчёт кластера. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b23cc.5040...@yandex.ru
Re: Виртуализация
21 марта 2013 г., 18:51 пользователь Артём Н. artio...@yandex.ru написал: И вся эта толпа гадит в одну DB :) Для СУБД это очень большая нагрузка или всё-таки не запредельная? Какие требуются минимальные ресурсы по памяти и CPU для 1000 хостов? Intel Dual Core 6400 4GB RAID10 MySQL InnoDB or PostgreSQL https://www.zabbix.com/documentation/2.0/manual/installation/requirements
Re: Виртуализация
21 марта 2013 г., 19:14 пользователь Артём Н. artio...@yandex.ru написал: 18.03.2013 11:08, Dmitry A. Zhiglov пишет: 18 марта 2013 г., 8:52 пользователь Stanislav Vlasov stanislav@gmail.com написал: поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Поддерживаю! Здравые аргументы! А если не нужно предупреждений и достаточно статистики для аналитики, то мне нравится munin. Выглядит неплохо. А если нужно и то, и то? Настраивается в /etc/munin/munin.conf #contact.someuser.command mail -s Munin notification someju...@fnord.comm #contact.anotheruser.command mail -s Munin notification anotheru...@blibb.comm Не пользовался этим. Надо бы воспользоваться и кажется, что меня munin устроит =)
Re: Виртуализация
21.03.2013 20:26, Dmitry A. Zhiglov пишет: 21 марта 2013 г., 18:51 пользователь Артём Н. artio...@yandex.ru написал: И вся эта толпа гадит в одну DB :) Для СУБД это очень большая нагрузка или всё-таки не запредельная? Какие требуются минимальные ресурсы по памяти и CPU для 1000 хостов? Intel Dual Core 6400 4GB RAID10 MySQL InnoDB or PostgreSQL https://www.zabbix.com/documentation/2.0/manual/installation/requirements О, извините, проглядел. Да, не хило для системы мониторинга. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b3cdd.5070...@yandex.ru
Re: Виртуализация
21.03.2013 20:31, Dmitry A. Zhiglov пишет: 21 марта 2013 г., 19:14 пользователь Артём Н. artio...@yandex.ru написал: 18.03.2013 11:08, Dmitry A. Zhiglov пишет: 18 марта 2013 г., 8:52 пользователь Stanislav Vlasov stanislav@gmail.com написал: поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Поддерживаю! Здравые аргументы! А если не нужно предупреждений и достаточно статистики для аналитики, то мне нравится munin. Выглядит неплохо. А если нужно и то, и то? Настраивается в /etc/munin/munin.conf #contact.someuser.command mail -s Munin notification someju...@fnord.comm #contact.anotheruser.command mail -s Munin notification anotheru...@blibb.comm Не пользовался этим. Надо бы воспользоваться и кажется, что меня munin устроит =) А штатные средства верещания приятным женским голосом там есть? :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514b3d7e.7070...@yandex.ru
Re: Виртуализация
21 марта 2013 г., 21:12 пользователь Артём Н. artio...@yandex.ru написал: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Например? Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси. Но дорого. Могу сказать, что для алертов лучше использовать нагиос. Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, Хм... Имелся ввиду доступ к хостам через хоста-посредника? Да. Тогда наиболее близкое - nrpe. А помимо Nagios? Смотря с какой целью. Для показометров с графиками - тот же cacti. Если воспользоваться написанием внешних скриптов - рисовать можно всё, что угодно. Я рисовал количество пользователей БД OpenEdge, например. Для оповещений о выходе параметров за границы - всё-таки nagios. К нему добавить к нему nconf (вебморда-конфигуратор) и приём snmp-алертов, чтоб о некоторых проблемах узнавать сразу, а не когда нагиос убедится, что это не из-за проблем со связью. Если нужен визуальный мониторинг чего сломалось - можно добавить nagvis и нарисовать карту или карты сети. Или подложить туда фотографию стойки и разложить индикаторы по нужным серверам. Использовал такое для того, чтобы дать оперативному дежурному средство узнать, в каком направлении сломалось и о чём сообщать. Показывать ему ВСЮ карту было излишним, так что он видел наиболее важные сервера + доступность удалённых точек. поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Желательны показометры. На мой взгляд, лучше не смешивать алерты и показометры. Если показометры нужны для начальства - тем более. И ведение чёрного ящика. Хм... Что имелось ввиду и чем недостаточен для этого удалённый сислог? А то, что жрёт: на него и кластер. Отдельный кластер для мониторилки - чересчур, по-моему. А если внутри кластера - получится, что под мониторилку выделены ресурсы, которых может не хватить для основных задач. Внутри кластера. Но отдельная ВМ. У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по количеству запросов в секунду и стала мешать соседям. Были установлены нагиос и какти, были натравлены на те же показатели, нагрузка стала на порядок меньше. Ещё хочу систему рез. копирования. Какую порекомендуете? Сильно зависит от того, как и что хотите копировать. Для файлов из линукса - rsnapshot неплох. У почтового сервера объём бекапа с историей за две недели составлял примерно 1.3 объёма от самого сервера. Да и у остальных серверов примерно также, так как менялись далеко не все файлы. Также очень даже неплоха bacula. Для БД - лучше что-то специализированное. Виртуалки целиком - для квм не знаю чего-либо готового, под Xen - аналогично. Делал снапшоты LVM и копировал диски целиком. -- Stanislav
Re: Виртуализация
Только если никто не будет заботиться о блокировках. У меня крутится кластер из 4 нод и 1 полки, на проксмоксе. 15 марта 2013 г., 12:31 пользователь Korona Auto Ltd.\ Andrey N. Prokofiev a...@korona-auto.com написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: и будут работать два гипервизора подключенные к одному схд по iscsi Получится мусор из данных. -- WBR, Andrey N. Prokofiev Phone: +7-812-645-3616 ext. 240 -- To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.**debian.orgdebian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/**5142DC48.7020201@korona-auto.**comhttp://lists.debian.org/5142dc48.7020...@korona-auto.com
Re: Виртуализация
19 марта 2013 г., 13:54 пользователь Artem Pastukhov ar...@mxk-m.ru написал: 15 марта 2013 г., 12:31 пользователь Korona Auto Ltd.\ Andrey N. Prokofiev a...@korona-auto.com написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: и будут работать два гипервизора подключенные к одному схд по iscsi Получится мусор из данных. Только если никто не будет заботиться о блокировках. У меня крутится кластер из 4 нод и 1 полки, на проксмоксе. clvm?
Re: Виртуализация
да 19 марта 2013 г., 15:39 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: 19 марта 2013 г., 13:54 пользователь Artem Pastukhov ar...@mxk-m.ru написал: 15 марта 2013 г., 12:31 пользователь Korona Auto Ltd.\ Andrey N. Prokofiev a...@korona-auto.com написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: и будут работать два гипервизора подключенные к одному схд по iscsi Получится мусор из данных. Только если никто не будет заботиться о блокировках. У меня крутится кластер из 4 нод и 1 полки, на проксмоксе. clvm?
Re: Виртуализация
Артём Н. artio...@yandex.ru wrote: 15.03.2013 18:31, Andrey Melnikoff пишет: Stanislav Vlasov stanislav@gmail.com wrote: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. proxmox со своим кластером вроде как умеет, но очень своеобразно. в прошлый раз, когда я трогал кластер из 2х нод - половина виртуалок не поднялась. В чём причина? Не разбирался, сильно было некогда. Что-то там кластер менеджер невнянтное писал про кворум. Да и его собственный автостартер виртуалок иногда творит чудеса. Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно^M получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен tools ему не нужен, оно само себе tools. Но с прициплением сторонних MIB'ов можно поиметь качественного сексу. на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? В последнее время, за что не возьмешься с гордой лейбочкой Enterprise на проверку оказывается дерьмом редкой категории. Жабикс крив по своей внутренней идеологии и организации. Унутре оно всё однопоточное, из-за этого обвешано нелепыми таймаутами. Импорт хостов с темплейтами может занимать несколько часов, при этом только php жрет память вагонами и греет процессор. Триггеры - хорошо, но пока нарисуешь что-то сложнее ой, у нас тут 0 вместо 1 - упаришься. Невозможность опросить итем по срабатыванию триггера это вобще 10+. Из-за этой мелочи приходиться хранить данные переодического опроса (хотя они не нужны и не менялись с предыдущей перезагрузки железа). Процесс апгрейда - занимательная песня, его просто нет. Проще выкинуть всё, что было и нарисовать с нуля но на новой версии. Великое достижение LLD в 2.0 работает, но криво. Итемы дисковерятся, графики создаются, но вот отключить опрос созданного таким образом итема или сменить название графика - нельзя. Много даст дежурному инженеру график с названием Traffic on interface Port9: 1000Base-SX/LX ? Из-за этой мелочи - на железку каждого типа приходиться держать 2 темплейта, один с автоматическими графиками, другой без графиков и рисовать их там вручную. Это для 1.8.x и для 2.0.x. А у нас всего ~600 свичей разных производителей. Бардак в темплейтах - страшный. Исправление триггера для конкретного свича - это песня. Карты? Это смех какой-то а не карты. Автодисковери? Еще тот глюкодром, быстрее написать скрипт с nmap'ом и через апи набить хостов в базу, но тут как всегда - там недописано, тут недоделано. Обработка состояния итемов? Упал итем в not supported и никак не догадаешься, по какой причине. Запуск внешних скриптов из zabbix_agentd достаточно часто эту проблему вызвает. Документация невнятная, типичный use case проще найти в форуме, чем в ней. Web-морда? Верх безумия. Посмотреть по быстрому, из-за чего сработал триггер (сами исходные данные) нельзя, надо мышкой повозить, повозить. Комменты к тригерам оператору показать - ни-ни-ни, это секретная информация. Это я еще промолчал как конфигурить zabbix_server и mysql под него. Еще вопросы будут? -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator of POST Ltd. mailto:temn...@kmv.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jmim1a-bpv@kenga.kmv.ru
Re: Виртуализация
19.03.2013 21:09, Andrey Melnikoff пишет: Еще вопросы будут? Со всеми вышеперечисленными минусами согласен. Что рекомендуешь использовать вместо заббикса? Надо: * графики - загрузка интерфейсов(mbits,pps), цпу, диска, памяти, ещё чего придумается * для добавления\редактирования хоста не требовало лезть в конфиги * наглядность событий хост жив, хост сдох, и подобные * учитывать что оператор, реагирующий на триггеры чуть умнее стола * собирать инфу как с snmp, так и с накого-то аналога zabbix-agent * уметь IPv6 * желательно уметь слать алерты на центральный сервер, особо не храня сведений там Заббикс хоть и крив и неудобен местами, но с этими задачами справляется. -- Best regards, Mikhail - WWW: http://www.antmix.pp.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Виртуализация
2013/3/20 Mikhail A Antonov b...@solarnet.ru Надо: * для добавления\редактирования хоста не требовало лезть в конфиги IMHO это скорее минус, чем плюс -- С уважением, Константин Матюхин
Re: Виртуализация
18 марта 2013 г., 8:52 пользователь Stanislav Vlasov stanislav@gmail.com написал: поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Поддерживаю! Здравые аргументы! А если не нужно предупреждений и достаточно статистики для аналитики, то мне нравится munin.
Re: Виртуализация
16.03.2013, 01:47, Артём Н. artio...@yandex.ru: 15.03.2013 18:31, Andrey Melnikoff пишет: Но если автору так хочется жабикс - то использовать dotdeb.org, там он свежий в отличии от стабильного в debian'e. Кстати, за ссылку репозиторий отдельное спасибо. Теперь, думаю, всё на Debian будет. У Zabbix есть свой репозиторий для Debian: https://www.zabbix.com/documentation/2.0/manual/installation/install_from_packages#debian_ubuntu -- С уважением, Роман Гуща -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/167791363663...@web11f.yandex.ru
Re: Виртуализация
15 марта 2013 г., 23:37 пользователь Артём Н. artio...@yandex.ru написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. Я не совсем правильно выразился. Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более приличное, конечно... Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, Хм... Имелся ввиду доступ к хостам через хоста-посредника? Тогда наиболее близкое - nrpe. поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. И не надо. Если нужна система, предупреждающая о том, что ща всё накроется и только - nagios. Если нужны показометры - таки да, zabbix. Хотя я как-то cacti обходился, там почему-то меньше жрало. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. Вот как раз с ними-то и была проблема - mysql при сборе данных с ~40 хостов по десятке датчиков на хост выжирал весь сервер до такой степени, что вебморда заббикса не каждый раз отображалась. Там, правда, сервер был не самый мощный из доступных и диски sata. Да, возможно, стоило бы потюнить мускль и убрать часть датчиков, но если учесть, что с тех времен стало почти 400 хостов - вряд ли бы заббикс потянул на том железе, что было выделено под nagios+cacti. А то, что жрёт: на него и кластер. Отдельный кластер для мониторилки - чересчур, по-моему. А если внутри кластера - получится, что под мониторилку выделены ресурсы, которых может не хватить для основных задач. -- Stanislav
Re: Виртуализация
16.03.2013 09:59, Hleb Valoshka пишет: On 3/15/13, Артём Н. artio...@yandex.ru wrote: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? raid1 поверх drdb? (предупреждаю сразу, кроме запуска на посмотреть опыта не имею) В смысле, RAID1, реализуемый DRDB? Да, я тоже думаю насчёт... Но пока ещё плохо ориентируюсь в данной области и про DRDB знаю мало. А возможно ли сделать сетевой RAID-5 через DRDB, как компромиссный вариант или такой возможности нет? Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс просто вы не умеете его готовить. вот посмотрите, что можно сделать из nagios: http://omdistro.org/. Жаль нет картинок... :-( Но при чём тут Nagios? OMD currently comes with the following software: nagios nagios-plugins nsca check_nrpe Icinga Shinken nagvis Оболочка для куча других систем мониторинга, помимо nagios (пусть даже и форков). Я скажу проще: http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems На вкус и цвет. Zabbix - одна из хороших систем. И для чего мне искать оболочку для Nagios, допиливать Nagios самому или писать свой NAgios, если в Zabbix всё и больше уже реализовано? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51441ecd.2020...@yandex.ru
Re: Виртуализация
16.03.2013 11:27, Артём Н. пишет: 16.03.2013 09:59, Hleb Valoshka пишет: On 3/15/13, Артём Н. artio...@yandex.ru wrote: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? raid1 поверх drdb? (предупреждаю сразу, кроме запуска на посмотреть опыта не имею) В смысле, RAID1, реализуемый DRDB? Да, я тоже думаю насчёт... Но пока ещё плохо ориентируюсь в данной области и про DRDB знаю мало. А возможно ли сделать сетевой RAID-5 через DRDB, как компромиссный вариант или такой возможности нет? Что-то я плохо соображаю... Ладно, возможно ведь, например, сделать пару RAID0, к примеру, на 2 Тб каждый. Затем объединить их в сетевой RAID1 по DRBD. На этом хранить наиболее критичные данные (образы ВМ, например, к тому же, много они не займут и 2 Тб хватит за глаза). У меня останется ещё 8 Тб. Два блочных устройства, которые я могу использовать исключительно под бэкапы. Если недоступно одно, бэкапы будут складываться на другое, на работу системы это никак не повлияет. И хранилища ВМ будут дублироваться. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514436f1.8080...@yandex.ru
Re: Виртуализация
Блин, DRDB. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5144371d.8090...@yandex.ru
Re: Виртуализация
Артём Н. writes: Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3ehffwsg1@comp.bungarus.info
Re: Виртуализация
16.03.2013 14:27, Maksym Tiurin пишет: Артём Н. writes: Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. А что происходит, при количестве хостов в несколько тысяч? И лучше ли масштабируемость у Nagios? На вики написано: Распределенный мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящихся на более высоком уровне иерархии. На сайте Zabbix: SCALABILITY Up-to 100,000 monitored devices Up-to 1,000,000 of metrics Thousands of checks per second Small to large distributed setups P.S.: В общем-то, столько агентов у меня не будет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51445011.5090...@yandex.ru
Re: Виртуализация
Артём Н. writes: Плохо маштабируется. Хотя если у вас нем нескольких тысяч хостов - можно и забикс использовать. А что происходит, при количестве хостов в несколько тысяч? Все хранится в одной RDBMS. ИМХО идею здравой назвать нельзя. Или по примеру Яндекса патчить Zabbix чтоб выносить статистику из DB на FS. (хотя можно взять Cacti в котором это из коробки :) И лучше ли масштабируемость у Nagios? В случае Nagios+конфиг-генератор маштабируемость лучше. Кроме того Nagios уже используется в больших конторах. И по граблам там уже прошлись первопроходцы. На вики написано: Распределенный мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящихся на более высоком уровне иерархии. И вся эта толпа гадит в одну DB :) На сайте Zabbix: SCALABILITY Up-to 100,000 monitored devices Up-to 1,000,000 of metrics Thousands of checks per second Small to large distributed setups P.S.: В общем-то, столько агентов у меня не будет. -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3620rw7t1@comp.bungarus.info
Re: Виртуализация
14.03.2013 20:11, Dmitry A. Zhiglov пишет: и будут работать два гипервизора подключенные к одному схд по iscsi Получится мусор из данных. -- WBR, Andrey N. Prokofiev Phone: +7-812-645-3616 ext. 240 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5142dc48.7020...@korona-auto.com
Re: Виртуализация
15 марта 2013 г., 12:31 пользователь Korona Auto Ltd.\ Andrey N. Prokofiev a...@korona-auto.com написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: и будут работать два гипервизора подключенные к одному схд по iscsi Получится мусор из данных. как бы вопрос на ваше замечание напрашивается
Re: Виртуализация
Stanislav Vlasov stanislav@gmail.com wrote: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. proxmox со своим кластером вроде как умеет, но очень своеобразно. в прошлый раз, когда я трогал кластер из 2х нод - половина виртуалок не поднялась. Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно^M получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Но если автору так хочется жабикс - то использовать dotdeb.org, там он свежий в отличии от стабильного в debian'e. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator of POST Ltd. mailto:temn...@kmv.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kunb1a-cpm@kenga.kmv.ru
Re: Виртуализация
15.03.2013 08:19, Stanislav Vlasov пишет: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. Я не совсем правильно выразился. Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс (да, я понимаю, что у Zabbix он неудобный, но у Nagios - это вообще незнамо что), . Всё, конечно, возможно допилить, но делать из Nagios Zabbix не хочется. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. А то, что жрёт: на него и кластер. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51435c6e.4030...@yandex.ru
Re: Виртуализация
15.03.2013 08:49, Konstantin Fadeyev пишет: Я бы предложил Proxmox, использование в нём kvm Тоже думаю, как один из вариантов, насчёт Proxmox+KVM или Xen. а для заббикса Ubuntu Server. Раздражает африканское слово. А чем Debian плох? :-\ Что вообще за недоделка этот ubuntu server (я не интересовался им)? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51435cf5.3080...@yandex.ru
Re: Виртуализация
15.03.2013 18:31, Andrey Melnikoff пишет: Stanislav Vlasov stanislav@gmail.com wrote: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. proxmox со своим кластером вроде как умеет, но очень своеобразно. в прошлый раз, когда я трогал кластер из 2х нод - половина виртуалок не поднялась. В чём причина? Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно^M получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51435ea0.6000...@yandex.ru
Re: Виртуализация
14.03.2013 20:11, Dmitry A. Zhiglov пишет: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. В дешевом варианте подойдет iSCSI. Создаете на одном сервере iSCSI initiator и подключаете storage по iSCSI. Так и сделаю. NFS - не вариант. iSCSI, судя по всему, - вполне хорошая идея. На storage нарезаем VG на LVM. Правда не скажу как поведет себя LVM в данном случае, возможно надо смотреть в сторону cLVM... надо бы почитать Я почитал. Только cLVM, поскольку, в случае с LVM будут конфликты из-за того, что ноды не будут видеть изменения, сделанные другими нодами. Плюс блокировки. Правда, их ведь должна обеспечивать кластерная ФС..? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51435fa8.5070...@yandex.ru
Re: Виртуализация
Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) +100500 за что-нибудь отличное от жабикса. Zabbix уже есть и настроен. Карты нарисованы, агенты установлены и отлажены, ген. директор просвещён и убеждён в полезности, инженеры просвещены и относительно довольны, кто-то из них даже диплом собрался по нему делать, закуплены SNMP адаптеры для ИБП (хотя SNMP tools сейчас корректно не установлен на машине, где крутится тестовый Zabbix), сделан Chromix с символикой и в стиле фирмы. Всё переделывать точно не буду, только переведу на 2-й Zabbix. По моим впечатлениям, очень даже неплохая система. Да, согласен web-интерфейс не очень удобен, да и сервер - бета в поздней стадии, но у него большие перспективы, широкие возможности и гибкость, достаточно продуманная организация. Чем он вам так не нравится? zabbiz гибок и очень хорош. в nagios нет такой логики построения тригеров и оповещений, да и много чего еще. -- В смысле осмысления бессмысленного смысл тоже имеет определенную осмысленность!!!
Re: Виртуализация
Да, а что вы всё про Proxomox да VirtManager? Что насчёт OpenStacK? Он ОЧЕНЬ интересен. И также Eucalyptus (кстати, на его основе ubunta-что-то-там-cloud крутится) и OpenNebula? Про другие-то системы? Чем хороши, чем плохи? Я, вообще, в сторону OpenStack как-то склоняюсь... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5143602d.6030...@yandex.ru
Re: Виртуализация
15 марта 2013 г., 20:51 пользователь Артём Н. artio...@yandex.ru написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. В дешевом варианте подойдет iSCSI. Создаете на одном сервере iSCSI initiator и подключаете storage по iSCSI. Так и сделаю. NFS - не вариант. iSCSI, судя по всему, - вполне хорошая идея. На storage нарезаем VG на LVM. Правда не скажу как поведет себя LVM в данном случае, возможно надо смотреть в сторону cLVM... надо бы почитать Я почитал. Только cLVM, поскольку, в случае с LVM будут конфликты из-за того, что ноды не будут видеть изменения, сделанные другими нодами. Плюс блокировки. Правда, их ведь должна обеспечивать кластерная ФС..? как я уже писал ранее iSCSI вариант только если SCST, а так NFS вполне вариант, естественно придется отказаться от LVM. По мне так файловые виртуалки как-то понадежнее чем на LVM особенно при работе со снапшотами. P.S. в качестве ОС на СХД можно использовать openfiler в нем есть и iscsi (iet) и NFS, поддерживает кластеризацию. -- В смысле осмысления бессмысленного смысл тоже имеет определенную осмысленность!!!
Re: Виртуализация
15.03.2013 22:20, Dmitry A. Zhiglov пишет: 15 марта 2013 г., 21:37 пользователь Артём Н. artio...@yandex.ru написал: Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. А то, что жрёт: на него и кластер. Наверное придется расстроить. Кластер - это не вычисление на двух серверах. Я не говорю про два сервера. Два на СХД. То есть суммировать ресурсы двух серверов у вас не получится. В любом случае, я могу установить СУБД на отдельной виртуальной машине и настроить балансировку нагрузки так, что она будет перекидываться на менее загруженный сервер. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514369ab.9040...@yandex.ru
Re: Виртуализация
15.03.2013 18:31, Andrey Melnikoff пишет: Но если автору так хочется жабикс - то использовать dotdeb.org, там он свежий в отличии от стабильного в debian'e. Кстати, за ссылку репозиторий отдельное спасибо. Теперь, думаю, всё на Debian будет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51436cd2.2090...@yandex.ru
Re: Виртуализация
15.03.2013 22:01, Павел Марченко пишет: 15 марта 2013 г., 20:51 пользователь Артём Н. artio...@yandex.ru написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. В дешевом варианте подойдет iSCSI. Создаете на одном сервере iSCSI initiator и подключаете storage по iSCSI. Так и сделаю. NFS - не вариант. iSCSI, судя по всему, - вполне хорошая идея. На storage нарезаем VG на LVM. Правда не скажу как поведет себя LVM в данном случае, возможно надо смотреть в сторону cLVM... надо бы почитать Я почитал. Только cLVM, поскольку, в случае с LVM будут конфликты из-за того, что ноды не будут видеть изменения, сделанные другими нодами. Плюс блокировки. Правда, их ведь должна обеспечивать кластерная ФС..? как я уже писал ранее iSCSI вариант только если SCST, а так NFS вполне вариант, естественно придется отказаться от LVM. По мне так файловые виртуалки как-то понадежнее чем на LVM особенно при работе со снапшотами. P.S. в качестве ОС на СХД можно использовать openfiler в нем есть и iscsi (iet) и NFS, поддерживает кластеризацию. Хм... Я уже смотрел его. Сейчас посмотрел более внимательно. А имеет смысл его использовать? Ведь, с одной стороны, я могу установить всё тоже самое и на Debian. С другой стороны, у OpenFiler есть web-интерфейс и настраивать надо гораздо меньше. Но с openfiler я не знаком, не знаю какие у него могут быть проблемы, не знаю его пакетного менеджера, не знаю, как у него с репозиториями. К тому же, там много встроенных фенечек, которые мне не требуются (тот же Active Directory, SAMBA, Kerberos и прочее). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51436f05.8060...@yandex.ru
Re: Виртуализация
15.03.2013 22:01, Павел Марченко пишет: 15 марта 2013 г., 20:51 пользователь Артём Н. artio...@yandex.ru написал: 14.03.2013 20:11, Dmitry A. Zhiglov пишет: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. В дешевом варианте подойдет iSCSI. Создаете на одном сервере iSCSI initiator и подключаете storage по iSCSI. Так и сделаю. NFS - не вариант. iSCSI, судя по всему, - вполне хорошая идея. На storage нарезаем VG на LVM. Правда не скажу как поведет себя LVM в данном случае, возможно надо смотреть в сторону cLVM... надо бы почитать Я почитал. Только cLVM, поскольку, в случае с LVM будут конфликты из-за того, что ноды не будут видеть изменения, сделанные другими нодами. Плюс блокировки. Правда, их ведь должна обеспечивать кластерная ФС..? как я уже писал ранее iSCSI вариант только если SCST, а так NFS вполне вариант, естественно придется отказаться от LVM. По мне так файловые виртуалки как-то понадежнее чем на LVM особенно при работе со снапшотами. Да, а про AoE что скажете? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51437462.9060...@yandex.ru
Re: Виртуализация
15 марта 2013 г., 22:34 пользователь Артём Н. artio...@yandex.ru написал: 15.03.2013 22:20, Dmitry A. Zhiglov пишет: 15 марта 2013 г., 21:37 пользователь Артём Н. artio...@yandex.ru написал: Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. А то, что жрёт: на него и кластер. Наверное придется расстроить. Кластер - это не вычисление на двух серверах. Я не говорю про два сервера. Два на СХД. То есть суммировать ресурсы двух серверов у вас не получится. В любом случае, я могу установить СУБД на отдельной виртуальной машине и настроить балансировку нагрузки так, что она будет перекидываться на менее загруженный сервер. Это вы на чтение или на запись собираетесь делать??
Re: Виртуализация
16.03.2013 00:52, Aleksandr Sytar пишет: 15 марта 2013 г., 22:34 пользователь Артём Н. artio...@yandex.ru написал: 15.03.2013 22:20, Dmitry A. Zhiglov пишет: 15 марта 2013 г., 21:37 пользователь Артём Н. artio...@yandex.ru написал: Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) Ну да, скорее упадёт стойка, привинченная к полу, чем СУБД. С MySQL+InnoDB вообще никаких проблем. А то, что жрёт: на него и кластер. Наверное придется расстроить. Кластер - это не вычисление на двух серверах. Я не говорю про два сервера. Два на СХД. То есть суммировать ресурсы двух серверов у вас не получится. В любом случае, я могу установить СУБД на отдельной виртуальной машине и настроить балансировку нагрузки так, что она будет перекидываться на менее загруженный сервер. Это вы на чтение или на запись собираетесь делать?? Это я всё-таки, наверное, погорячился. :-| Перекидывание дороже выйдет. Но с тем, что суммировать ресурсы двух серверов у вас не получится я не согласен: мне кажется, что балансировку возможно сделать так, что производительность будет не сильно ниже, чем сумма производительностей серверов. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51438dd9.8050...@yandex.ru
Re: Виртуализация
On 3/15/13, Артём Н. artio...@yandex.ru wrote: Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй? raid1 поверх drdb? (предупреждаю сразу, кроме запуска на посмотреть опыта не имею) Мне nagios не понравился. Не такой гибкий, как Zabbix, меньше возможностей, всяких там графиков, нет распределённого мониторинга (нужен на перспективу, поскольку некоторые машины только во внутренних сетях), менее приятный интерфейс просто вы не умеете его готовить. вот посмотрите, что можно сделать из nagios: http://omdistro.org/.
Re: Виртуализация
14.03.2013 20:11, Dmitry A. Zhiglov пишет: 12 марта 2013 г., 22:10 пользователь Артём Н. artio...@yandex.ru написал: Одну СХД на три сервака - вот что точно нужно. Хотелось бы СХД разместить на 2-х серверах, которые имеют по 6 Тб (для моих нужд пока вполне хватит), но не хотелось бы задействовать их исключительно по СХД. Возможно ли? Или лучше не стоит? По СХД, кстати, больше всего вопросов... Это ветка еще актуальна? Актуальна. Я, пока что, читаю про облачные системы. Прочитал первое сообщение. Должна быть выстроена система мониторинга и архивирования с высокой степенью доступности. Верно? Да. С оговоркой: должна быть система с высокой степенью доступности. Но запихнуть всю серверную в облако мне никто не даст. :-) В общем-то, я хочу сделать облако для себя, на свой риск. Не дадут возможности - уволюсь. Что бы перетекали виртуалки (не делал на linux) нужен shared storage. В дешевом варианте подойдет iSCSI. Да, думаю OpenISCSI. Создаете на одном сервере iSCSI initiator и подключаете storage по iSCSI. На storage нарезаем VG на LVM. Правда не скажу как поведет себя LVM в данном случае, возможно надо смотреть в сторону cLVM... надо бы почитать Вот и будут работать два гипервизора подключенные к одному схд по iscsi Прочитал статью, в которой как раз описывалось, как организовать СХД на cLVM и OpenISCSI. Правда, в качестве ВМ там использовался OpenVZ и Proxmox. OpenVZ не хочется. Дальше ставится kvm (предпочитаю именно его) Использую его на своём компьютере с qemu. Мне тоже нравится. Но любопытно было бы пощупать Xen. Имеет смысл? и на какой либо машине Debian c gui на котором запускаем virtmanager, подключаемся удаленно к гипервизору и настраиваем. Только этот virtmanager не все умеет, и надо смотреть на его возможность. Мне он так не нравится... Может, есть что-то лучше, чем virt-manager? Может, Proxmox? СХД. Видел как ставят небыстрые и ёмкие схд и получается следующее: наступает в организации профилактика и вся дежурная смена начинает по задании верховного руководства делать бэкапы акронисом и ничего не успевают сделать за 4-8 часов профилактики или успевают частично. Упираются или в производительность схд (физическую способность) или в пропускную способность сетевого интерфейса или в то, что копируют не raw а files несколько десятков миллионов россыпью. Похожая ситуация. Бэкапы есть только частичные. Была ситуация: перезагрузили шлюз во время текущих работ. Шлюз не поднялся. Остался единственный второй шлюз. Когда принесли диск шлюза, оказалось, что ext3 сильно разрушена. Бэкапа нет. Даже акронисового и гхостового. С трудом восстановил настройки ПО, которое стояло на шлюзе, буквально по кускам. Здесь надо бы смотреть на общую ситуацию, выдумывать сценарии, опрашивать клиентов пользующиеся соответствующими сервисами, разрабатывать план бэкапирования и план восстановления. Внутренняя сеть. Клиентов опрашивать, в основном, без толку. Им нужно, чтобы если свалится какой-либо из серверов, знать какие кнопки нажать, чтобы быстро его восстановить (краткая простая инструкция). А что я там разверну, их, надеюсь, не волнует. По правде говоря, облако там не очень-то и нужно. Я просто хочу освоить инструмент. Отсюда вытекает требование на реакцию вашей системы хранения на эти планы и насколько организация готова простаивать пока поднипите что-то из бэкапа. По-идее, там горячее резервирование каждой машины. Поэтому, простаивать там вряд ли она будет. Если же действительно будет простой и реальная задержка в функционировании, да ещё и по вине сети или службы, которая за неё отвечает, будут ОЧЕНЬ большие потери и очень серьёзные разборки, которые повлекут, как минимум, лишение премий. С учётом того, что к данной организации я не отношусь (есть сейчас модное слово аутсорсинг), плакал мой кластер, в случае простоя... Ну а далее можно тасовать диски в raid 1, 10, 50, 60 или что-то еще и разделять критичные и быстрые данные на быстрые устройства, а те что могут покурить на более медленные. Набросок, касательно СХД (поправьте, где неправильно): 1. Есть две машины по 6-ть дисков на 1Тб. 2. Создаю программный RAID средствами mdadm (не знаю есть ли аппаратный контроллер, но, скорее всего, нет). Может, RAID1? С другой стороны, я не уверен, что мне хватит 6 Тб. Тут надо думать. Могу ли я обойтись только LVM и не использовать mdadm? На каждой из машин конфигурация одинакова. 4. Устанавливаю на каждой из машин хранилища OpenISCSI. Впоследствии - на каждой ноде кластера. Имею два блочных устройства. 5. Создаю разделы на устройствах. Три раздела: для ВМ, для хранилища копий, например, и один резервный. 6. Создаю три группы cLVM, в каждую из которых входит один раздел. 7. Создаю логические тома. пока не знаю, наверное, всё-таки будет один том на группу, поскольку разграничивать там нечего. 8. Создаю ФС. Например, GFS2. То, что не нравится: 1.Получается, что ВМ находятся на одном сервере. Если он выходит из строя, нет ВМ. Возможно ли как-то сделать так, чтобы ВМ были размазаны
Re: Виртуализация
14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) -- Stanislav
Re: Виртуализация
Я бы предложил Proxmox, использование в нём kvm, а для заббикса Ubuntu Server. 15 марта 2013 г., 10:19 пользователь Stanislav Vlasov stanislav@gmail.com написал: 14 марта 2013 г., 22:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Что бы перетекали виртуалки (не делал на linux) нужен shared storage. Не нужен, а очень желателен. В случае kvm более-менее свежих версий возможна живая миграция с одного хоста на другой одновременно с копированием данных. Заббикс Много не скажу, здесь, и не только здесь, есть более опытные коллеги которые работают с ним ежедневно, я лишь пока планирую его внедрить во 2-3 квартале. Все может упереться с схд на БД, если очень много хостов и тикеров будет. Некоторые рекомендации на сайте заббикса можно получить из документации, отсюда и плясать. Могу сказать, что для алертов лучше использовать нагиос. Жрёт сильно меньше и не требует базы данных, которая тоже может упасть :-) -- Stanislav -- Константин Фадеев
Re: Виртуализация
12.03.2013 09:11, Nikolay Panov пишет: А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? А я везде debian и пускаю. Либо stable либо testing. Мне нет нужды пускать винду или ещё что-то с левыми ядрами. Поэтому плюсы OpenVZ для меня перевешивают всех прочих. Ну да, пишут, что: падение производительности составляет всего 1-3 %, по сравнению с обычными Linux-системами. Но хочется, чтобы в перспективе возможно было поставить всё, что захочу... И я почитал про OpenStack. Очень интересно... Любопытен ещё Xen Cloud, да ещё и какая-то OpenNebula есть, оказывается. Ещё имеется такая любопытная штука, как Pacemaker: http://clusterlabs.org/ http://habrahabr.ru/post/107837/ Причём, всё это есть в Debian репозитории. Мне нравится сама идея: иметь пулы ресурсов, из которых возможно легко выделять дисковое пространство, память, целые виртуальные машины. И в которые легко добавлять новые ресурсы просто воткнув новую машину. Пока есть время почитать и очень интересно какие у этих систем достоинства и недостатки, особенно в сравнении между собой... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513f4b3a.4020...@yandex.ru
Re: Виртуализация
12.03.2013 00:54, Maksym Tiurin пишет: Артём Н. writes: 10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? Тогда Xen. Можно будет запускать и так и так (паравиртуальные юниксы и виртуальные любые). Я загорелся идеей облачной платформы. :-) Хочу. Возможно, получится выбить побольше железа (как минимум три сервака хоть получится, для начала) под свои нужды и попробовать... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513f4bcf.7000...@yandex.ru
Re: Виртуализация
12 марта 2013 г., 19:37 пользователь Артём Н. artio...@yandex.ru написал: 12.03.2013 00:54, Maksym Tiurin пишет: Артём Н. writes: 10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? Тогда Xen. Можно будет запускать и так и так (паравиртуальные юниксы и виртуальные любые). Я загорелся идеей облачной платформы. :-) Хочу. Конечно все зависит от задач, но по моему опыту, очень часто узким место является СХД Чем лучше СХД и путь от хранилки до серверов, тем комфортнее потом будет. Возможно, получится выбить побольше железа (как минимум три сервака хоть получится, для начала) под свои нужды и попробовать... Одну СХД на три сервака - вот что точно нужно.
Re: Виртуализация
12.03.2013 21:11, Dmitry A. Zhiglov пишет: 12 марта 2013 г., 19:37 пользователь Артём Н. artio...@yandex.ru написал: 12.03.2013 00:54, Maksym Tiurin пишет: Артём Н. writes: 10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? Тогда Xen. Можно будет запускать и так и так (паравиртуальные юниксы и виртуальные любые). Я загорелся идеей облачной платформы. :-) Хочу. Конечно все зависит от задач, но по моему опыту, очень часто узким место является СХД Чем лучше СХД и путь от хранилки до серверов, тем комфортнее потом будет. Возможно, получится выбить побольше железа (как минимум три сервака хоть получится, для начала) под свои нужды и попробовать... Одну СХД на три сервака - вот что точно нужно. Хотелось бы СХД разместить на 2-х серверах, которые имеют по 6 Тб (для моих нужд пока вполне хватит), но не хотелось бы задействовать их исключительно по СХД. Возможно ли? Или лучше не стоит? По СХД, кстати, больше всего вопросов... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513f6f83.8080...@yandex.ru
Re: Виртуализация
Артём Н. writes: 10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? Тогда Xen. Можно будет запускать и так и так (паравиртуальные юниксы и виртуальные любые). -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3k3pdac94@comp.bungarus.info
Re: Виртуализация
А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? А я везде debian и пускаю. Либо stable либо testing. Мне нет нужды пускать винду или ещё что-то с левыми ядрами. Поэтому плюсы OpenVZ для меня перевешивают всех прочих. Have a nice day, Nikolay. 2013/3/10 Артём Н. artio...@yandex.ru 10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c8c03.6050...@yandex.ru
Re: Виртуализация
Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). 1. Была возможность лёгкого подключения других аппаратных серверов. А установить debian, развернуть на нём openvz, ввести ноду в кластер - достаточно просто? Первые два пункта можно упростить до воткнуть baremetal сидюк с proxmox, ответить на пару вопросов о сети при инсталляции. 2. Была возможность распределения нагрузки по серверам. Это в каком смысле? Load balancing делается средствами внешними по отношению к виртуалкам обычно. Например, можно иметь несколько A записей для вашего домена, что даст почти бесплатный load balancing. Ну или можете попробовать поиграться с openstack (это примерно аналог амазоновской системы). Но он куда сложнее разворачивается чем openvz или vmware. 3. Была возможность миграции запущенных ОС с одной физической машины на другую. Это есть. 4. Был централизованный интерфейс для управления всем этим (желательно WEB-интерфейс). Это есть. Have a nice day, Nikolay. 2013/3/10 Артём Н. artio...@yandex.ru Требуется сделать систему резервного копирования для сети и систему мониторнига. Для этого выделяют пару (если ещё найду, то больше) серверов с не очень мощным CPU (Core2 Duo, вроде), который имеет VT-x, но с более ли менее нормальным объёмом дискового пространства (~12 Тб). В качестве системы мониторинга будет Zabbix. В качестве системы рез. копирования планирую использовать Bacula. Хочу попробовать сделать всё на виртуальных машинах. До этого виртуализацию использовал только десктопе, так что практических навыков нет (затем и хочу попробовать). Для начала одна машина для Zabbix, одна для Bacula, одна для всего прочего (возможно также понадобится отдельный брандмауэр/IDS, поскольку, хотя сеть и внутренняя, кто там только не ползает). Под Zabbix-машину хочу использовать Arch (поскольку в Debian до сих пор нет Zabbix 2.x), под всё остальное - Debian. Посоветуйте, что использовать и как организовать систему так, чтобы: 1. Была возможность лёгкого подключения других аппаратных серверов. 2. Была возможность распределения нагрузки по серверам. 3. Была возможность миграции запущенных ОС с одной физической машины на другую. 4. Был централизованный интерфейс для управления всем этим (желательно WEB-интерфейс). Возможно ли подключать более старые машины, которые не имеют поддержки аппаратной виртуализации? Сейчас смотрю в сторону Xen, думаю насчёт VmWare Server и любопытствую про OpenVZ. Серьёзно пока не занимался вопросом: систем много, хотя бы подскажите на что ориентироваться? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c7ff1.6030...@yandex.ru
Re: Виртуализация
10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). Посмотрел. Выглядит весьма симпатично (хотя и не очень современно). Интерфейс не перегружен, вроде: мне нравится. 1. Была возможность лёгкого подключения других аппаратных серверов. А установить debian, развернуть на нём openvz, ввести ноду в кластер - достаточно просто? Первые два пункта можно упростить до воткнуть baremetal сидюк с proxmox, ответить на пару вопросов о сети при инсталляции. Да, это то, что надо. CD, думаю, не нужен. Лучше сразу с образа разворачивать (разве что, потому придётся подкорректировать размер разделов). 2. Была возможность распределения нагрузки по серверам. Это в каком смысле? Load balancing делается средствами внешними по отношению к виртуалкам обычно. Например, можно иметь несколько A записей для вашего домена, что даст почти бесплатный load balancing. У меня внутренняя сеть (из диапазона 10.x.x.x), которая не связана с Интернет. И, как правило, обращений людей к серверам не будет вообще (разве что просмотр интерфейса Zabbix и, в крайнем случае, управление системой рез. копирования (тут я пока ещё не решил насчёт интерфейса)). Обращения агентов идут по IP, поскольку DNS сервера прописаны не на всех машинах. Т.е., мне нужно, чтобы был кластер, который равномерно распределяет нагрузку по всем физическим машинам. Какими средствами это реализуется? Ну или можете попробовать поиграться с openstack (это примерно аналог амазоновской системы). Но он куда сложнее разворачивается чем openvz или vmware. Сейчас посмотрю. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c8b96.7090...@yandex.ru
Re: Виртуализация
10.03.2013 17:18, Nikolay Panov пишет: Имею дело с OpenVZ. Замечаний нет. Для руления контейнерами использую оболочку proxmox (это не единственный вариант, есть и другие, несколько). А что насчёт KVM? Ведь, с OpenVZ, я так понимаю, смогу запускать только Linux с тем же ядром, что и хост-ОС..? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c8c03.6050...@yandex.ru
Re: Виртуализация
Ну или можете попробовать поиграться с openstack (это примерно аналог амазоновской системы). Но он куда сложнее разворачивается чем openvz или vmware. Количество пакетов удручает. Сейчас посмотрю видео с обзором, которое у них на сайте. Но, судя по краткому описанию, система серьёзная, хотя ещё и не совсем понятно, что с ней делать. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c8d06.6000...@yandex.ru
Re: Виртуализация
26 сентября 2012 г., 23:11 пользователь Dmitry A. Zhiglov dmitry.zhig...@gmail.com написал: Ваша задача - хорошая работа для аналитика, никак не для компьютерных гиков. Аналитик должен ... привлечь экспертов. Переработать и выдать результат. OT: В небольших организациях сисадмин, зачастую, и аналитик и эксперт и саппорт. А позволить себе аналитика с экспертами могут, наверное, те конторы, у которых денег куры не клюют. Основная задача, решаемая аналитиком с экспертами, как наиболее наукообразно оформить отъем денег у организации, с больными на голову топ-менеджерами, полагающими, что вложение достаточного количества денег во всякие модные аббревиатуры позволит им избежать персональной ответственности в случае краха их империи. -- DamirX
Re: Виртуализация
27 сентября 2012 г., 9:47 пользователь Скубриев Владимир vladi...@skubriev.ru написал: А какие сетевые карты и коммутаторы вы используете ? У меня, например, 3com. Кстати есть еще один + от виртуализации win серверов: помещая win на виртуальную машину получаем беспроблемную интеграцию с VLAN, который, как известно, под офтопиком реализуется в драйвере сетевой карты и далеко на всякая умеет. Даже на железных настоящих серверах. -- DamirX
Re: Виртуализация
27.09.2012 10:25, Damir Hakimov пишет: 27 сентября 2012 г., 9:47 пользователь Скубриев Владимир vladi...@skubriev.ru написал: А какие сетевые карты и коммутаторы вы используете ? У меня, например, 3com. Кстати есть еще один + от виртуализации win серверов: помещая win на виртуальную машину получаем беспроблемную интеграцию с VLAN, который, как известно, под офтопиком реализуется в драйвере сетевой карты и далеко на всякая умеет. Даже на железных настоящих серверах. -- DamirX А можно более конкретно какое оборудование ? Чтобы можно было ориентироваться на будущее. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5063f679.7060...@skubriev.ru
Re: Виртуализация
27 сентября 2012 г., 10:47 пользователь Скубриев Владимир vladi...@skubriev.ru написал: А какие сетевые карты и коммутаторы вы используете ? У меня, например, 3com. А можно более конкретно какое оборудование ? Чтобы можно было ориентироваться на будущее. 3Com Baseline switch 2250, 2226 - железяки довольно старые, но пашут 24*7 уже... лет 5, наверное. С сетевыми картами Я голову не ломаю уже года 3 как. Noname, конечно, не ставлю. lspci | grep net 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) 02:06.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] (rev 8b) 02:07.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10) Первая из них - интегрированная. Тут следует сделать небольшое отступление. В том месте, где это эксплуатируется - воздух не совсем положительно влияет на здоровье. Тут компьютеры, чаще всего, ластиком ученическим ремонтируют: потер контакты - он, зараза, и заработал. Это, кстати, одна из причин, почему мне нужна живая миграция: чтоб не останавливать сервис на время планового обслуживания - протирания контактов ластиком. Но даже в таких условиях, самым уязвимым местом оказались шпиндели. Я даже backup сервер выключать стал, в надежде, что это продлит ему жизнь. DVD-приводы у нас расходный материал: 3-6 месяцев и всё :-( Злые языки утверждают, что у них пластиковые (или из чего их там делают?) линзы портятся. -- DamirX
Re: Виртуализация
Но даже в таких условиях, самым уязвимым местом оказались шпиндели. Я даже backup сервер выключать стал, в надежде, что это продлит ему жизнь. DVD-приводы у нас расходный материал: 3-6 месяцев и всё :-( Злые языки утверждают, что у них пластиковые (или из чего их там делают?) линзы портятся. DVD-приводы очень боятся были.. если не секрет, как/зачем вы используете DVD-приводы? Мы уже http://www.youtube.com/watch?v=zf7JibyVgzw#! их все ) Один взяли внешний для общего пользования на всякий случай
Re: Виртуализация
On Thu, Sep 27, 2012 at 03:36:56PM +0400, Anatoly Molchanov wrote: Но даже в таких условиях, самым уязвимым местом оказались шпиндели. Я даже backup сервер выключать стал, в надежде, что это продлит ему жизнь. DVD-приводы у нас расходный материал: 3-6 месяцев и всё :-( Злые языки утверждают, что у них пластиковые (или из чего их там делают?) линзы портятся. DVD-приводы очень боятся были.. если не секрет, как/зачем вы используете DVD-приводы? Мы уже http://www.youtube.com/watch?v=zf7JibyVgzw#! их все ) Один взяли внешний для общего пользования на всякий случай Вроде и спам, и вроде и не спам. -- WBR, wRAR signature.asc Description: Digital signature
Re: Виртуализация
DVD-приводы очень боятся были.. если не секрет, как/зачем вы используете DVD-приводы? Мы уже http://www.youtube.com/watch?v=zf7JibyVgzw#! их все ) Один взяли внешний для общего пользования на всякий случай Вроде и спам, и вроде и не спам. Это не спам, а глагол. Автора ролика не знаю, кот не мой. * аналогично Возьмитию
Re: Виртуализация
27.09.2012 14:55, Anatoly Molchanov пишет: +100 ))) Действительно хороший пример получился. А какие сетевые карты и коммутаторы вы используете ? Самые бюджетные. Почти все плюшки разумных коммутаторов создают точки отказа, поэтому беру самые простые, сетевухи - соответственно тоже. Несколько Asus P8B-C/4L, четыре коммутатора с 16 портами 1Gb(FD) - серверы общаются на каналах с 8Gb (причем это Ethernet), стоило копейки. Коммутаторы 1U по высоте и 8,5 в ширину (т.е. два коммутатора в один юнит). Корпусы беру 2хюнитовые под ATX блоки питания, бюджетные SSD. Спасибо, думаю очень ценная информация. И альтернативное решение: Свитч оптический (стоимость моих коммутаторов и одного сервера) + дисковая полка HP (стоимость оставшихся серверов), сервера сложно сравнивать, но в результате решение в 6 раз дороже (не считая софта). Естественно настал день, когда оптику поломал дежурный админ, естественно не было инструмента для обжима под рукой именно в этот день. Через полгода использования выяснили, что оптика готова была бы пропустить больше инфы, но узким местом стала полка. Недавно вышел из строя блок питания сервера, вендор сообщил что машина не поддерживается и блоков таких уже нет, месяца два искали - купили б/у на eBay ))) У самого 2 сервера hp ml150g6. Два потому, что изначально планировалось отказоустойчивость решения. Вышел из строя один базы sql подняли на другом. Второй конечно используется - но опять же из-за того, что нет денег на третий. А так планировалось, что второй будет на случай выхода из строя первого. Шеф говорил так - раз мы покупаем такие дорогие железки = значит вряд ли они поломаются т.к. очень качественные. Наивный он - но с ним спорить бесполезно -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506532ad.9040...@skubriev.ru
Re: Виртуализация
26 сентября 2012 г., 2:09 пользователь Павел Марченко bbl...@gmail.comнаписал: в случае с ксеном провал удаления снапшота - неизвестно что делать дальше т.к. он фактически остался и никакими средствами его не удалить. Остались файлы, разделы lvm или данные в каких-то базах? Речь идёт о Citrix Xen Server, правильно я понимаю? когда с одним сервером что-то не так и нужно срочно раскидывать машины по остальным, не всегда есть под рукой машина на которой свободно 8 гиг оперативы, а есть к примеру со свободными 6 гигами, временно кидаешь туда, пока все не перебалансируешь на время ремонта сервера и т.п. Полезно, не спорю. Но разве esxi стоит дешевле нового сервера? Павел, смысл данной темы не в том чтобы спорить(хотя в споре рождается истина), я так полагаю нам всем тут есть чем заняться и без этого, а в том чтобы сделать какие-то выводы. Вот я и задал вопрос. Спорить можно и в другом месте - и не факт что кто-то переспорит. Может стоит попытаться объеденить усилия, смоделировав реальную ситуацию: как решить ту или иную задачу на различных готовых и самодельных гипервизорах на debian. Вопрос изначально был задан в сторону того, что обладают ли готовые брендовые решения всеми своими преимуществами о которых стоит задуматься в пользу выбора данного продукта, или же всё таки лучше самоделки допиливать, а возможно и вкладывать в них какие-то денюжки..
Re: Виртуализация
Функции; Удобство использования; Производительность; Надежность; Безопасность; Масштабируемость; Требования по поддержке развитию; Стоимость и удобство обслуживания; Требования к документированию; Совместимость; Переносимость; Подготовка персонала; Требования к оборудованию и смежному ПО; Вы не представляете компанию-интегратора? Это основной печень для навязывания VmWare/Xen :) Смоделировать процесс работы это обязательно (с этого нужно начинать, но автор не сообщил к сожалению условия) Под означенные пункты и без заморочек: поставить несколько гипервизоров, нагрузить 50% vm'ами и настроить ha-правила для восстановления работы vm на другом свободном гипере в случае потери физической ноды позволит любое решение. Но возможность иметь 50%ный запас позволит только свободное решение, т.к. вместо лицензии на VmWare можно физический сервер взять той же производительности Может быть в отрыве от темы, но хотелось бы услышать мнение админов небольших предприятий. Брендовый сервер имеет спаренный блок питания, память с ECC, raid-массив, стоит X рублей, все же имея точки отказа. Я за эти Х рублей беру 2-3 небрендовые машины той же производительности что и рассматриваемый сервер. Отказоустойчивость реализую для группы, а не для машины (нет специфичных блоков, raid'ы были 0, теперь просто ssd). Многие коллеги осуждают мою политику, но периодически сидят-курят в ожидании спецов из IBM, которые должны поменять в течении двух рабочих дней глючную материнку на важном инстансе. Мне же природная лень и отказоустойчивый кластер не позволяют идти чинить машину, если у нее downtime меньше недели. Но IBM+VmWare, по их мнению, круче моих поделок. Мне застрелиться или допилить уже балансировщики нагрузки?
Re: Виртуализация
Полностью поддерживаю Мы по началу тоже покупали брендовое железо но потом пришли к выводу что за эти деньги можно взять несколько не брендовых и на них настроить отказоустойчивую кластеризацию Видел как слетают и 60 Raid на брендовых железках Единственный минус это что в стойке больше шума будет и следить за кластером посложнее чем за 1 крутой железкой Но выходит из строя один узел то запчасти продают в любом первом же маге а на брендовое железо купите батарейку в первом маге -Original Message- From: Anatoly Molchanov ykdo...@gmail.com To: Dmitry A. Zhiglov dmitry.zhig...@gmail.com Cc: debian-russian@lists.debian.org Date: Wed, 26 Sep 2012 23:49:59 +0400 Subject: Re: Виртуализация Может быть в отрыве от темы, но хотелось бы услышать мнение админов небольших предприятий. Брендовый сервер имеет спаренный блок питания, память с ECC, raid-массив, стоит X рублей, все же имея точки отказа. Я за эти Х рублей беру 2-3 небрендовые машины той же производительности что и рассматриваемый сервер. Отказоустойчивость реализую для группы, а не для машины (нет специфичных блоков, raid'ы были 0, теперь просто ssd). Многие коллеги осуждают мою политику, но периодически сидят-курят в ожидании спецов из IBM, которые должны поменять в течении двух рабочих дней глючную материнку на важном инстансе. Мне же природная лень и отказоустойчивый кластер не позволяют идти чинить машину, если у нее downtime меньше недели. Но IBM+VmWare, по их мнению, круче моих поделок. Мне застрелиться или допилить уже балансировщики нагрузки?
Re: Виртуализация
26.09.2012 23:49, Anatoly Molchanov пишет: Функции; Удобство использования; Производительность; Надежность; Безопасность; Масштабируемость; Требования по поддержке развитию; Стоимость и удобство обслуживания; Требования к документированию; Совместимость; Переносимость; Подготовка персонала; Требования к оборудованию и смежному ПО; Вы не представляете компанию-интегратора? Это основной печень для навязывания VmWare/Xen :) Смоделировать процесс работы это обязательно (с этого нужно начинать, но автор не сообщил к сожалению условия) Под означенные пункты и без заморочек: поставить несколько гипервизоров, нагрузить 50% vm'ами и настроить ha-правила для восстановления работы vm на другом свободном гипере в случае потери физической ноды позволит любое решение. Но возможность иметь 50%ный запас позволит только свободное решение, т.к. вместо лицензии на VmWare можно физический сервер взять той же производительности Может быть в отрыве от темы, но хотелось бы услышать мнение админов небольших предприятий. Брендовый сервер имеет спаренный блок питания, память с ECC, raid-массив, стоит X рублей, все же имея точки отказа. Я за эти Х рублей беру 2-3 небрендовые машины той же производительности что и рассматриваемый сервер. Отказоустойчивость реализую для группы, а не для машины (нет специфичных блоков, raid'ы были 0, теперь просто ssd). Многие коллеги осуждают мою политику, но периодически сидят-курят в ожидании спецов из IBM, которые должны поменять в течении двух рабочих дней глючную материнку на важном инстансе. Мне же природная лень и отказоустойчивый кластер не позволяют идти чинить машину, если у нее downtime меньше недели. Но IBM+VmWare, по их мнению, круче моих поделок. Мне застрелиться или допилить уже балансировщики нагрузки? +100 ))) Действительно хороший пример получился. А какие сетевые карты и коммутаторы вы используете ? -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5063e87a.3050...@skubriev.ru
Re: Виртуализация
24.09.2012 12:50, Павел Марченко пишет: P.S. 50+ гипервизоров 400+ виртуалок это же сколько денег ))) -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5063e8e8.9070...@skubriev.ru
Re: Виртуализация
VLAN: All of these settings could be done from the web-interface ( http://pve.proxmox.com/wiki/Vlan) DRBD используется в самом Proxmox'е для обеспечения высокой доступности, зачем поднимать DRBD между гостевыми системами? (это как минимум лишает основных бонусов виртуализации, связанных со свободным переносом ВМ) Если хочется, чтобы Proxmox вел себя иначе и не лез в ваши специфичные настройки, исходные коды доступны из репы. патчи никто не отменял 25 сентября 2012 г., 8:52 пользователь Damir Hakimov damir.haki...@gmail.com написал: 24 сентября 2012 г., 17:07 пользователь Anatoly Molchanov ykdo...@gmail.com написал: Proxmox 1.9/2.0 (первая попроще, вторая посерьезнее уже), немцы делают, строго на Debian (годами крутится, забот не знаю) Раз пошла такая пьянка - режь последний огурец (С) От себя добавлю: Proxmox - вещь, возможно, перспективная. Для дебьяновцев еще и привычная. Но следует быть готовым к тому, что некоторые вещи настроить через ГУЙ не получится. DRBD нужно будет настроить самостоятельно руками. VLAN - лучше тоже руками. После настройки сети мне пришлось сказать chattr +i /etc/network/interfaces, дабы шибко умный Proxmox своим гуем не лез куда не надо. После настройки, впрочем, с созданием виртуальных машин любой эникейщик справится. -- DamirX
Re: Виртуализация
25 сентября 2012 г., 10:21 пользователь Anatoly Molchanov ykdo...@gmail.com написал: VLAN: All of these settings could be done from the web-interface (http://pve.proxmox.com/wiki/Vlan) Ну... как-бы на заборе тоже много чего написано... не соответсвующего реальности. DRBD используется в самом Proxmox'е для обеспечения высокой доступности, зачем поднимать DRBD между гостевыми системами? Я разве говорил, что у меня DRBD между гостевыми системами? А между нодами его нужно настраивать по-старинке. (Да еще, возможно, придется DRBD свежий компилировать) Но, оно того стоит, конечно. Если хочется, чтобы Proxmox вел себя иначе и не лез в ваши специфичные настройки, исходные коды доступны из репы. патчи никто не отменял Сравните: chattr +i супротив берем исходные коды из репы находим... правим... отлаживаем... -- DamirX
