LINUX.ORG.RU
ФорумAdmin

Посоветуйте, покритикуйте, виртуализация, архитектура.

 


5

5

Доброго всем вечера!

dyasny, справедливо посоветовал мне создать отдельный топик, и собственно по-делу тоже обещал высказаться. Прошу совета, и адекватной критики.

Задача: обслуживать сеть, на 200 персон. С примерным набором ПО: Oracle, apache, samba, 1C, ejabberd, openmeeting, freeradius, postgesql, postfix и проч. - Сервисов очень прилично, но они все не высоконагруженные, они просто разные.

Хочется: как можно меньше ломаться, и после сбоя быстро подниматься. Как можно проще управляться. Как можно дешевле обходиться. И как можно проще отлаживаться/обновляться - т.е. иметь возможность поднять копию любого виртуализованного сервиса.

Есть несколько географически разнесённых комнатушек/серверных, соединенных между собой 1гбит. сетью общего пользования (в разных зданиях).

Есть 2 сервера, с 32гб. ОЗУ, одна машинка без ECC с 64 гб., и пару машинок с 16гб. ОЗУ.

Как можно организовать то, что я хочу имея то, что имею сейчас? То есть без покупки: NAS или построения SAN. Без покупки свитчей с поддержкой больших кадров, и скоростями 10гбит/сек.

Сейчас, мне всё это видится следующим образом:

Сервер с 64гб. озу, выделяется под backup. + на нём выполняются не критичные VM, не требующие backup - учебные машины, или копии продуктивных систем для тестов.

ansible, который может управлять узлами с KVM + к нему: rundesk. Web лицо для kvm: WebVirtMgr.

На узлах с KVM, будет использована zfs, при помощи которой раз в некоторое время я буду получать снепшоты, и передавать их по LAN, на сервер backup. + На сервер backup передавать xml определения libvirt от машин.

Если у меня выйдет из строя совсем что-то жёстко, то я смогу подняться с backup. Если мне нужно перенести машину с железа, на железо: то можно использовать или сам kvm, он умеет вроде что-то делать. Или выключить VM, и перенести дельту снепшота и подняться на backup сервере временно. - В общем такие нюансы устраивают Руководство, но всё же, мне хочется подумать, над вариантами.

Какие варианты я рассматривал:

купить дублированную SAN, ПО для виртуализации, сервера для архивации - дорого.

oVirt, с GlusterFS, но... Тут возникает вопрос, что ей нужна очень хорошая сеть, чего я тоже не могу предоставить, даже если я всё поставлю в одной серверной комнате, то, у меня я думаю гагибита моего не хватит. И плюс ко всему меня настораживает, что oVirt, всё же полигон для RHEVа. И БОЛЬШЕ всего мне не понятен тут вопрос с резервированием образов виртуальных машин при таком раскладе, а именно: не ясно, что делать в случае повреждения GlusterFS? Ведь она получается вообще никак не резервируется, и если у меня побьётся по какой-либо причине образ VM, мне не откуда будет взять резервный образ. Зато появится онлайн миграция, и удобная управлялка, ну и ввод в строй нового узла - будет очень простым делом. Но прибавится гемор по сопровождению версий ovirt + резервирования engine. - В общем, на мой взгляд тут больше оверхеда и минусов, чем плюсов реальных для меня.

облака: не подходят, ибо дорого. Облачные машинки с 12 гб ОЗУ и 500 гб стораджа - нынче очень не дешёвые. Так же все перенести в облако не получится, а гибридное облако тоже те ещё страдания... Интернет канал не быстрый. В основном все работают из одной точки. А облака, это больше для паблик сервисов - ИМХО.

Особых идей больше нету. Что скажет уважаемый all?

★★★★★
Ответ на: комментарий от DALDON

И последнее: если ты делаешь один вирт.диск под систему, один под своп и один под данные, то как-минимум ты можешь разместить их на разных физ. носителях: ssd, hdd, NFS/FC (не сейчас так в будущем)

sdio ★★★★★
()
Ответ на: комментарий от DALDON

короче, мое мнение - тебе надо перепланировать весь этот зоопарк. а дальше - или ты выбиваешь бчджет на нормальное решение, или остаешься с нагромождением всего на всем.

openstack тут это перебор - не те масштабы и не те задачи. oVirt тоже подходит слабо - он рассчитан на датацентры а не на мелочь безпузую которую ты пытаешься задействовать. остаются всякие левые решения типа proxmox, kimchi, wibvirtmgr и т.д.

если вы найдешь все таки бюджет, то тогда можно говорить о серьезной имплементации, и поверь мне, оно этих денег стоит, не только для тебя, но и для всей организации. просто это тяжело понять если не мыслишь категориями ROI на 3-5 лет вперед.

если найдется бюджет на SAN или NAS, или хотя бы приличную железку с кучкой гигабиток и дисков, то можно говорить о начале проекта, который объединит все твое железо в один управляемый датацентр. Ну а когда начальники отделов прочухают все ништяки от таких перемен, они сами тебя поддержат перед советом директоров или кто там у вас одобряет финансы, и можно будет наращивать мощности. благо ovirt/rhev расширяются не в пример vmware, на порядки лучше.

все твои потуги с zfs/lvm/хз-что-еще это попытка слепить из говна пулю, и вряд ли намного улучшит положение как оно уже имеется. я считаю что надо или кардинально все менять на серьезную систему, или оставить все как есть и только подкручивать гайки тут и там по мелочам

dyasny ★★★★★
()
Ответ на: комментарий от dvrts

ну там список фичеров говорит сам за себя. на днях демонтрировал ovirt одному из core-ов oslo и ceilometer, он смотрел, смотрел, а потом выдал «боже мой, как же убог этoт наш openstack»

dyasny ★★★★★
()
Последнее исправление: dyasny (всего исправлений: 1)
Ответ на: комментарий от dvrts

ну потому что несерьезно это. когда у меня одна-две машинки я могу там городить всякую хрень руками. но когда их одна-две сотни, надо использовать стандартные решения с полки. zfs в линуксе пока еще не там. многослойные извращения - сам в них запутаешься. ansible/salt/етц конечно помогут навести стандартизацию даже если взять за стандарт ту самую пулю из известной субстанции, но я считаю что даже это - лишнее. вот посмотри на тот же cinder - у тебя в нем один api, и тебе должно быть пофиг что там за ним, это не твоя проблема. в ovirt то же самое, ты просто оперируешь коннектами к схд и виртуальными дисками, а где они лежат и в каком виде тебя волновать не должно.

иначе ты или вручную делаешь кучку телодвижений при каждом изменении конфигурации, с довольно высоким шансом напортачить, или пишешь собственные скрипты за работоспособность которых ты отвечаешь сам (сомневаюсь что ты на свои плейбуки и скрипты натравливаешь настоящих QAщиков)

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

когда у меня одна-две машинки

Bare metal хостов для виртуализации или самих VM внутри?

zfs в линуксе пока еще не там

Еще нет, но уже вполне.

или пишешь собственные скрипты за работоспособность которых ты отвечаешь сам

Да, угадал.

dvrts ★★★
()
Ответ на: комментарий от dvrts

Bare metal хостов для виртуализации или самих VM внутри?

не имеет значения.

Еще нет, но уже вполне.

он вряд ли вообще будет «там» - проблемы с лицензией. zfs - мощная штука, но пока она не окажется в линуксе, она останется нишевой.

Да, угадал.

а кто тебя проверяет? откуда ты знаешь что твои скрипты не свалятся в самый ответственный момент, или не сломают ничего?

в ovirt или где?

в openstack

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

поэтому у меня саого стоит staging backup server с zfs на борту, раду дедупликации, но если мне скажт что нам надо таких кучу, я пошлю говорящего лесом. более того, если мне понадобится даже еще один такой, я откажусь его делать, и куплю полку с дисками.

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

ovirt хорошая штука, но его привязка только к редхату и его клонам огорчают.

городить всякую хрень руками. но когда их одна-две сотни

zfs + собственные скрипты у меня прекрасно справляются с 3-4 десятками виртуалок на одном физическом сервере, суммарно виртуалок за сотню.

axelroot
()
Ответ на: комментарий от DALDON

не сходится с той концепцией, что мне сейчас представляют

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

axelroot
()
Ответ на: комментарий от axelroot

И ты доволен сим творчеством? Чем рулишь виртуалками? Поднимаешься с бекапов хоть иногда? :)

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

доволен

более чем

Чем рулишь

консоль и виртманагер

Поднимаешься с бекапов

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

axelroot
()
Ответ на: комментарий от axelroot

Ну ок! Стало быть пока поработаю в этом ключе. А там - посмотрим.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от axelroot

ovirt хорошая штука, но его привязка только к редхату и его клонам огорчают.

это в первую очередь управлялка для kvm, ничего что kvm привязан к red hat, так как разрабатывается, обкатывается и тестируется в первую очередь именно там? ну и чтоб два раза не вставать, вполне реально использовать дебиан или даже генту, только это было бы как стрелять самому себе в ногу.

zfs + собственные скрипты у меня прекрасно справляются с 3-4 десятками виртуалок на одном физическом сервере, суммарно виртуалок за сотню.

я чрезвычайно рад.

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

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

это и имелось в виду

axelroot
()
Ответ на: комментарий от axelroot

А сообщества других дистрибутивов что-нибудь делают для того, чтобы на их дистрибутивы можно было поставить oVirt без выстрелов по своим конечностям?

kernelpanic ★★★★★
()
Ответ на: комментарий от kernelpanic

canonical обещали, даже выделили человека, только воз и ныне там, видимо идеальный коричневый оттенок для обоев важнее :)

на самом деле, если кто нибудь закомиттит набор пакетов под $distro его с радостью примут, они там не снобы

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

ко всему что касается kvm и libvirt

т.е. использовать kvm за пределами красношапочных дистров это стрельба по своим ногам, интересно это еще почему?

axelroot
()
Ответ на: комментарий от axelroot

потому что можно избежать кучи багов всего лишь сменив дистр. в отличии от дебиана и убунту, kvm и libvirt даже в федоре проходят профессиональное тестирование, а до rhel доходит практически железобетонный гипервизор

dyasny ★★★★★
()
Ответ на: комментарий от axelroot

ну да, одним работать а другим с багами мучиться.

dyasny ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.