Как устроена консоль в Xen'е

[easy_john]

Особо комментировать тут нечего, так что давай я потроллю немного:
Когда же будет облако в московском ДЦ!
:)

[amarao]

А я и не про облако рассказываю, это про Xen.

Насколько я могу судить, такое описание консоли Xen'а — первое не только на русском языке, но и «вообще». Все описания, которые я видел ранее, либо описывали только техническую часть «как починить», либо описывали теоретическую часть с фреймбуфферами. А вот про использование псевдотерминалов и слушающего vncterm'а, прицепившегося к этим псевдотерминалам — нет.

[easy_john]

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

[amarao]

Я могу сказать, что сейчас у виртуалок в облаке аптайм много больше, чем у хостов. Я нашёл мелкую багу в конфигурации, пришлось ребутить всё облако. Машины клиентов перемигрировали и продолжили работать.

Основным ключевым фактором для виртуальных машин является не облако (которое совсем взаимозаменяемое), а хранилище.

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

[easy_john]

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

Ну хранилище можно несложно реплизировать в пределах ДЦ в соседние помещения.
А во втором инстансе достаточно иметь некого вотчера, который следит за первым и в случае проблем — запустит машины у себя.

Интересует запас прочности не теоретический, а именно тот, который заложен у вас.
В теории то можно сделать вообще неубиваемый гео-распределенный кластер — это только вопрос цены.

[amarao]

Во-первых, на Цветочной (где всё расположено) нет «других помещений», здесь очень большой машинный зал. И пожара тут точно не будет, с учётом того, сколько тут всякого «пожаротушения» налеплено.

Возможность репликации по тёмным волокнам — рассматривается, возможно, будет.

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

[easy_john]

точно не будет — это не показатель.

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

ЗЫ кстати, есть очень хороший ресурс xgu.ru/, я часто консультируюсь с ним, когад что-то настраиваю, да и сам по мелочам что-то добавлял. Вот там про xen не очень мног, ты бы мог заметно добавить.

[amarao]

Смерть чего либо, кроме хранилища чревата, максимум, даунтаймом. Для большинства объектов облака — сравнимым с ребутом. Если вылетит экстрим, который 10G SAN по оптике делает, возможно, будет некоторая деградация производительности дисковой подсистемы.

Конфигурация облака такова, что на хостах ничего, кроме логов, не хранится.

А новый хост я подниму минут за 15.

[xen32]

Простите, а вот этот вот ваш xen, он бывает 32 битным там например?
Ещё раз извините, я не в теме и статью не читал, мне чисто по названию.

[amarao]

Да, бывает. Xen поддерживает кучу архитектур помимо x86, а на самом x86 он поддерживает i386, PAE, x86_64.

[easy_john]

ты говоришь о поддержке гостевых машин, а вопрос был про сам ксен.

[amarao]

xen может работать на процессорах без x86_64. Правда, запускать такие машины он не сможет, да.

[easy_john]

но можно ли при этом ксен для x86 назвать xen32 (собственно это ник челвоека, потому он и спрашивает)

[unicast]

ИМХО, это философский вопрос, т.к. постфикс «32» родился в win-религии. В nix есть просто «приложение, работающее под архитектурой X»

[easy_john]

пожалуй нет.

[unicast]

А как вы в итоге будете отдавать клиентам «консоль»?
VNC over SSL?

[amarao]

Тс… вот сделаем, расскажем. Но будет охрененно, это я точно могу сказать.

[feedbee]

Забавно, я консоли для VPS пока ни у кого не видел. И юзкейс для всего этого дела только один вижу: если пользователь поломал себе сеть или SSH, то другого способа зайти на машину просто нет. Но стоит ли овчинка выделки? Гемороя много, а толку вроде нет.

[xdenser]

А мне вот интересно есть ли ограничение на размер framebuffer, и какое?

[amarao]

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

Плюс, если говорить про HVM, то разрешения определяются поддержкой их эмулируемой железкой.

[drunken]

в domU можно «пробрасывать» физические устройства

ну и добавить бы, что для этого жизненно необходим VT-d или IOMMU, который нечасто попадается на десктопных процессорах/материнках

в реальной жизни (в серверной виртуализации) такой метод не используется

с видеокартами — конечно нет, но вот с другим оборудованием — очень даже :)

[amarao]

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

Во-всяком случае я не совсем понимаю, как выглядит миграция виртуалки, привязанной к железке.

Хотя, в XCI что-то на эту тему начали пилить…

[drunken]

это понятно, что без миграции.
но ведь не каждая среда виртуализации — облако :)

[amarao]

Кстати, повторю, кажется, в XCI над этой проблемой работают. Но я глубоко в это не влазил, там свой мир.