Использовать ли вирт машины? Роутер для офиса в вирт. машине..

Конечно сделай. С точки зрения безопасности наилучшее решение - это одна машина на одну роль. Виртуализация немного тебя к этому решению приблизит ценой небольшого оверхеда, который у современных систем с паравиртуализацией невелик. Плюс, слегка поднимешь скиллы, что сделает тебя ценнее. Ставь центос 6.5 (на нем, на мой взгляд, проще всего все поднять) с XEN и вперед. Немного придется повозиться (скорее даже потрахаться) с конфигурацией сети, но там все вполне осиляемо.

На одном сервере без общего стораджа смысла в виртуализации не много

А что за общий сторадж?

конечно вирт-машины.
kvm в руки и с песней! =)

если не планируешь failover, смысла в виртуализации никакого, только дополнительные тормоза.

общий сетевой диск. Если дохнет один сервер, ВМ запускаются на другом

Использую openvz на работе и lxc дома. Накладных расходов 0 - все службы по контейнерам, изолированы друг от друга. Советую

В общем никакого аварийного переключения не планируется. Можем себе позволить кратковременный простой. Но, чтобы быстро восстановить работу - нужно развернуть систему на другом железе. Поэтому сейчас делается полный бэкап средствами lvm + tar. Если что - берем пусть даже простой ПК, раскатываем бэкап, правим несколько конфигов - и в бой. С виртуалками хочется сделать нечто подобное. Чтобы в случае чего - запуститься на дрегом железе и работать далее.

Но зачем?

С точки зрения логики и безопасности решение «Одна машина для одной задачи» весьма и весьма годно. Виртуализация хоть и не то же самое, но в какой-то мере. Так что сделай.

Меня только немного пугает настройка сети, потому что планируется использовать 4 VLAN: две группы пользователей, открытый WI-FI и видеонаблюдение. В принципе можно хоть сейчас раскатать бэкап имеющейся системы и запускаться - настраивать виланы на подсети. Но надо будет подумать насчет raid - оставлять mdadm или довериться рэйд-контроллеру сервера.

конечно аппаратный raid лучше софтового, даже думать нечего

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

В моей предыдущей конторе так и было. Купили один сервер и все остальные древние тачки на склад. Все в виртуалках было : ad, касперский,джаббер, 1с, файлохранилище,фтп. Очень удобно. Снапшоты,бекапы делать.

kvm + zvol (ZOL) + аппаратный raid в режим jbod + снапшоты vm на резервный серв.

для сетей vlan, uml-utilities, bridge-utils

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

использовать zfs

паравиртуализацией

Зачем если есть аппаратная виртуализация?

XEN

Ненужно, ибо есть KVM

Снапшоты

использовать zfs

Чтобы увеличить вероятность пропажи данных?

конечно аппаратный raid лучше софтового, даже думать нечего

Блин, хватит уже распространять этот бред.

С бэкапами само собой. Дело в том, что аппаратным рейдом я не пользовался. С mdadm все просто: умер диск - меняем, умер компьютер - втыкаем диски в новый компьютер, проверяем синхронизировался ли массив (raid1).

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

Рейд не отменяет необходимости бекапов

Нет, нельзя.

Вот это меня и пугает. Почитал, пишут, что B120i - контроллер, который используется в моем сервере - не что иное как fakeraid. Но опять на него как-то завязаны салазки дисков, которые мограют о состоянии массива и говорят можно ли извлекать диск в текущий момент.

Чтобы увеличить вероятность пропажи данных?

епт. знаток мля. попробуй завали эту фс, потом пиши глупости.

аппаратная виртуализация?

Зачем тебе для какого-нибудь жаббер-сервера аппаратная виртуализация? Чтобы накладные расходы были ощутимее?

Ненужно, ибо есть KVM

KVM does not support paravirtualization for CPU (http://www.linux-kvm.org/page/FAQ)

Чтобы увеличить вероятность пропажи данных?

Да ты - вообще эксперт, как я погляжу. ZFS, конечно, не лучший выбор на линуксе, но «увеличить вероятность пропажи данных» - это мощно.

епт. знаток мля. попробуй завали эту фс, потом пиши глупости.

Под фрей оно годно, я не спорю. А под линукс уже готово?

Зачем тебе для какого-нибудь жаббер-сервера аппаратная виртуализация? Чтобы накладные расходы были ощутимее?

Если нет аппаратной виртуализации я б юзал уже контейнеры. Xen стремительно превращается в ненужно.

Да ты - вообще эксперт, как я погляжу. ZFS, конечно, не лучший выбор на линуксе, но «увеличить вероятность пропажи данных» - это мощно.

Тег sarcasm

Не пугайся, делай бекапы

KVM does not support paravirtualization for CPU (http://www.linux-kvm.org/page/FAQ)

Вот в том-то и дело, что KVM работает с аппаратной виртуализацией только. Надеюсь, ты не будешь спорить и утверждать что с паравиртуализацей оверхед не хуже, чем с аппаратной?

т.е. отдельный raid-контроллер, с кэшем, будет хуже справляться, чем софтовый рейд? производители сторажей нас обманывают, и SAN не нужен? ну да, бред конечно.

т.е. отдельный raid-контроллер, с кэшем, будет хуже справляться, чем софтовый рейд?

Сначала нужно определить значение фразы «хуже справляться».

производители сторажей нас обманывают, и SAN не нужен?

Мы вроде про аппаратные RAID-контроллеры говорим, при чём тут SAN? И да, SAN нужны не всем и не всегда, как и аппаратные RAID-контроллеры.

А под линукс

ZOL - http://zfsonlinux.org/

kvm on zfs - Очередной тред выбора бакапов (комментарий)

Сначала нужно определить значение фразы «хуже справляться».

в случае дисковой подсистемы это означает, естественно, iops и ширину канала передачи данных. ну и всякие полезные плюшки для raid, типа hotswap, поддерживаемые типы массивов и пр.

Мы вроде про аппаратные RAID-контроллеры говорим, при чём тут SAN? И да, SAN нужны не всем и не всегда, как и аппаратные RAID-контроллеры.

в данном конкретном случае, возможно, не нужно ни то, ни другое, поскольку нагрузки на дисковую подсистему не предвидится. с другой стороны, если речь идет про виртуализацию, целесообразно все же тот самый storage (да хоть бы и нищебродский iSCSI, а не FC), тот самый SAN, и failover cluster. в ином случае профита от виртуализации я лично не вижу.

lxc + docker

в случае дисковой подсистемы это означает, естественно, iops и ширину канала передачи данных.

ИМХО тут аппаратные контроллеры выигрывают у софтового рейда только при большом количестве дисков и высокой цене контроллера =).

ну и всякие полезные плюшки для raid, типа hotswap, поддерживаемые типы массивов и пр.

По этому пункту софтовый рейд (вместе с другими фичами линуксовой дисковой подсистемы) рвёт как тузик тряпку почти все аппаратные решения.

Ты забыл ещё одно: удобство использования. У аппаратных рейдов с этим всё традиционно плохо: у каждого производителя своё глючное проприетарное говнецо, которое поддерживает полтора дистрибутива. Ну и, конечно же, баги фирмвари, куда же без них 8).

в данном конкретном случае, возможно, не нужно ни то, ни другое, поскольку нагрузки на дисковую подсистему не предвидится. с другой стороны, если речь идет про виртуализацию, целесообразно все же тот самый storage (да хоть бы и нищебродский iSCSI, а не FC), тот самый SAN, и failover cluster. в ином случае профита от виртуализации я лично не вижу.

Профит в изоляции сервисов друг от друга.

конечно аппаратный raid лучше софтового, даже думать нечего

Особенно когда контроллер выходит из строя.

ИМХО тут аппаратные контроллеры выигрывают у софтового рейда только при большом количестве дисков и высокой цене контроллера =).

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

По этому пункту софтовый рейд (вместе с другими фичами линуксовой дисковой подсистемы) рвёт как тузик тряпку почти все аппаратные решения.

Ты забыл ещё одно: удобство использования. У аппаратных рейдов с этим всё традиционно плохо: у каждого производителя своё глючное проприетарное говнецо, которое поддерживает полтора дистрибутива. Ну и, конечно же, баги фирмвари, куда же без них 8).

есть неплохой профит при использовании отдельных storage-й, в которых да, хардварные контроллеры и проприетарная прошивка, но на выходе тот же iSCSI, например. и почему меня должно волновать, как оно внутри устроено? поддерживается, соответственно, везде.

не знаю, как там дела с HP, но с IBM было у нас пара случаев, которые закончились заменой полки без потери инфы (все RAID были восстановлены)

docker

Не вижу смысла в применении в данном контексте

есть неплохой профит при использовании отдельных storage-й, в которых да, хардварные контроллеры и проприетарная прошивка, но на выходе тот же iSCSI, например.

В конексте темы никакого профита от отдельного стораджа нет.

не знаю, как там дела с HP, но с IBM было у нас пара случаев, которые закончились заменой полки без потери инфы (все RAID были восстановлены)

Сколько был простой?

Я бы не брал вирутализацию. Если у тебя будет железной сбой - все равно ляжет все. А так лишние костыли.

В конексте темы никакого профита от отдельного стораджа нет.

согласен, в контексте темы - никакого.

Сколько был простой?

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

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

Вот в том и весь фокус, что у тебя были ещё два стораджа с теми же данными. А если бы он был всего один - то всё сложилось бы иначе.

Вот в том и весь фокус, что у тебя были ещё два стораджа с теми же данными. А если бы он был всего один - то всё сложилось бы иначе.

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

в сабжевом случае при смерти этого единственного сервера тоже будет простой, вне зависимости от типа рейда внутри. и даже ребилд рейда обернется простоем. но им оно не критично, как говорит ТС.

в сабжевом случае при смерти этого единственного сервера тоже будет простой, вне зависимости от типа рейда внутри.

Вероятность найти «такой же» аппаратный RAID-контроллер в наличии в ближайшем компьютерном магазине обычно околонулевая. Так что простой может получиться сильно дольше. В случае с софтверным рейдом можно просто те же диски вставить в другой системник.

Ещё раз напоминаю, что мы говорим про «офисный сервак».