Да, бывает и такое извращение. Когда железо бытовое для уменьшения цены, и не осилить покупку простейших квм по 5к, начинаются маразмы "загрузитесь в консоль восстановления, поднимите qemu, и потом.."
Собственно, сама команда
qemu-system-x86_64 \
-m 2048M \
-net nic -net user \
-enable-kvm \
-cpu host,nx \
-M pc \
-smp 2 \
-vga std \
-drive file=/dev/sda,format=raw,index=0,media=disk \
-drive file=/dev/sdb,format=raw,index=1,media=disk \
-vnc :0,password \
-monitor stdio
Полная версия
https://habr.com/ru/company/selectel/blog/464565/
И да, страдает таким маразмом именно селектел. То, что хецнер сделал лет 15 назад (подключаемые kvm), для них пока недостижимый прогресс. Минимум тем, что не увидеть что сейчас на сервере творится, что за ошибки в консоли и подобное. Не всегда ребут возможен, минимум тем что текущее состояние аварии гораздо важнее простоя из-за режима восстановления.
Показаны сообщения с ярлыком selectel. Показать все сообщения
Показаны сообщения с ярлыком selectel. Показать все сообщения
вторник, 3 марта 2020 г.
вторник, 16 июля 2013 г.
resize2fs: Couldn't find valid filesystem superblock.
Например:
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
resize2fs: Device or resource busy while trying to open /dev/vg-www/www
Couldn't find valid filesystem superblock.
Для нас было актуально, когда надо было ресайзить /var/www без перезагрузки системы и желательно даже без отмонтирования раздела, благо облако selectel такое позволяет, и даже LVM уже умеет на лету увеличиваться. Проблема оказалась чисто в изменении размера раздела.
UP: как оказалось, эта ошибка в_том_числе значит, что нужно было сделать fsck (на отмонтированном разделе опять же). Вот такая тут магия.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
resize2fs: Device or resource busy while trying to open /dev/vg-www/www
Couldn't find valid filesystem superblock.
Для нас было актуально, когда надо было ресайзить /var/www без перезагрузки системы и желательно даже без отмонтирования раздела, благо облако selectel такое позволяет, и даже LVM уже умеет на лету увеличиваться. Проблема оказалась чисто в изменении размера раздела.
UP: как оказалось, эта ошибка в_том_числе значит, что нужно было сделать fsck (на отмонтированном разделе опять же). Вот такая тут магия.
понедельник, 3 июня 2013 г.
Настройка IPv6 на Debian/Ubuntu/Owncloud (из памятки селектела)
Настройка сервера в режим работы на чистом IPv6
среда, 2 января 2013 г.
Особенности хостинга в облаке selectel
К сожалению, их облако имеет довольно серьезные баги, приводящие к зависанию машин. А их оправдания "это баги линукса" выглядят нелепо, учитывая что те же дистрибутивы на реальном железе и всяких вдс работают годами без зависаний, а чуть загрузишь их машины и они виснут... Как будто они специально их портят, чтобы сваливать всё на "баги линукса", тем более что при этом проц ест на 100% и им дополнительный профит, а без АПИ даже автоматическую перезагрузку не сделать. Поэтому ВСЕГДА используйте системы мониторинга типа той же яндекс.метрики, ибо оно любит падать.
Пример:
3 сервера на дебиане, разом упали.
selectel: Здравствуйте. Ваша машина 123 зависла, на консоль выводила трейс ядра. Машина перезапущена с помощью принудительного выключения (операция доступна на вкладке «Управление» по ссылке «Опасные операции») с последующим включением.
Сбоев в работе облачной инфраструктуры, на которой был запущен этот сервер, зафиксировано не было. Подобные дедлоки возникают из-за ошибок в коде выполняющихся внутри виртуальной машины программ, ядра операционной системы или его модулей.
мы: Судя по тому, что легли все сервера, сбой таки был.
И потом, там дебиан, а он на пустом месте не падет никогда, что подтверждает, что проблемы с вашей стороны были.
selectel: сбои в инфраструктуре никогда не вызвают последствий, описанных в Вашем вопросе выше - при наличии внешнего сбоя либо становится недоступным диск машины, либо перезагружается весь сервер.
Трассировка, вызванная работой сервера является нормальным явлением, вызванным ошибкой в коде или недостатком ресурсов и проявляется аналогичным и на физических серверах.
---
При этом баги такого рода встречались _исключительно_ у них. Что на фоне их более чем адекватного саппорта вызывает недоумение, зачем они используют эти детские отмазки и почему машины могут работать месяцами, но стоит подать на них нагрузку, и они падают в течении суток-двух, а потом и под нагрузкой работают по несколько недель.
Пример:
3 сервера на дебиане, разом упали.
selectel: Здравствуйте. Ваша машина 123 зависла, на консоль выводила трейс ядра. Машина перезапущена с помощью принудительного выключения (операция доступна на вкладке «Управление» по ссылке «Опасные операции») с последующим включением.
Сбоев в работе облачной инфраструктуры, на которой был запущен этот сервер, зафиксировано не было. Подобные дедлоки возникают из-за ошибок в коде выполняющихся внутри виртуальной машины программ, ядра операционной системы или его модулей.
мы: Судя по тому, что легли все сервера, сбой таки был.
И потом, там дебиан, а он на пустом месте не падет никогда, что подтверждает, что проблемы с вашей стороны были.
selectel: сбои в инфраструктуре никогда не вызвают последствий, описанных в Вашем вопросе выше - при наличии внешнего сбоя либо становится недоступным диск машины, либо перезагружается весь сервер.
Трассировка, вызванная работой сервера является нормальным явлением, вызванным ошибкой в коде или недостатком ресурсов и проявляется аналогичным и на физических серверах.
---
При этом баги такого рода встречались _исключительно_ у них. Что на фоне их более чем адекватного саппорта вызывает недоумение, зачем они используют эти детские отмазки и почему машины могут работать месяцами, но стоит подать на них нагрузку, и они падают в течении суток-двух, а потом и под нагрузкой работают по несколько недель.
пятница, 12 октября 2012 г.
Немного об оборудовании разных хостеров
Кто-то эту информацию скрывает, кто-то -- нет. Например, у selectel и fastvps эта информация доступна по запросу.
Пока по 2 компаниям, наиболее интересные моменты, возможно потом дополню другими.
selectel, dedicated
Серверы Intel Atom D525 работают на материнской плате: Supermicro X7SPA-HF.
Серверы Intel Xeon E3-1230 работают на материнской плате: Supermicro X9SCL-F.
FastVPS
EX4
–
Mainboard Asus P8H67
CPU Intel Core i7-2600
RAM 16 GB DDR3
HDD 2*(Seagate) 3 TB 7200rpm
EX6
–
Mainboard Asus P8B WS
CPU Intel® Xeon® Processor E3-1245
RAM 16 GB DDR3 ECC
HDD 2*(Constellation ES.2) 3TB 7200 rpm
EX8
–
Mainboard Asus P8B WS
CPU Intel® Xeon® Processor E3-1275
RAM 16 GB DDR3 ECC
HDDs can be chosen.
KVM
вторник, 25 сентября 2012 г.
selectel снова лежит...
В очередной раз у селектела проблемы, только в этот раз они отмалчиваются. Около 22 часов ноды отпали, около 23 одна на небольшое время вернулась в строй и снова отпала. 2:24, всё пока лежит, информации нет. Печально.
UP
В 7 утра ответили:
"В результате сбоя в работе сетевого оборудования, возникла проблема со стабильностью связи между хостами виртуализации и хранилищами, данные не затронуты. В настоящий момент работа сети стабилизировалась, и идет запуск всех машин, которые работали до сбоя."
Но по системам мониторинга последние ноды запустились только в 11.30.
Очередной "хороший" сбой более чем на 12 часов.
UP2
Колбасит дальше.
"К сожалению, произошла потеря связности в сети передачи данных.
Ответственным специалисты уже извещены, ведутся восстановительные работы.
Срок восстановления ориентировочно, составит несколько часов."
UP
В 7 утра ответили:
"В результате сбоя в работе сетевого оборудования, возникла проблема со стабильностью связи между хостами виртуализации и хранилищами, данные не затронуты. В настоящий момент работа сети стабилизировалась, и идет запуск всех машин, которые работали до сбоя."
Но по системам мониторинга последние ноды запустились только в 11.30.
Очередной "хороший" сбой более чем на 12 часов.
UP2
Колбасит дальше.
"К сожалению, произошла потеря связности в сети передачи данных.
Ответственным специалисты уже извещены, ведутся восстановительные работы.
Срок восстановления ориентировочно, составит несколько часов."
Мотает 15 часов уже.
UP3
Итог. Колбасило 25 часов, аптайм был менее 50%. Интересно, что у них случилось, что всё лежало так долго.
Итог: http://habrahabr.ru/company/selectel/blog/152351/
UP3
Итог. Колбасило 25 часов, аптайм был менее 50%. Интересно, что у них случилось, что всё лежало так долго.
Итог: http://habrahabr.ru/company/selectel/blog/152351/
среда, 22 августа 2012 г.
selectel: увеличиваем диск
Для паркинга уже была инструкция, теперь для selectel, уже вкратце.
Имеем: отдельный диск под /var/www, расположенный на диске /dev/xvdb, целиком отданным под lvm, с именем vg--www-www (группа vg-www, имя www), путь /dev/vg-www/www
Вариант с выключением для изменения размера -- вменяемых описаний, как это делать без перезагрузки, пока не найдено. Есть дока, но по ней не получилось.
Размер в панели уже увеличен.
Для начала, надо будет отмонтировать раздел. (umount)
Смотрим где наш том
pvdisplay
Растянем на весь новый диск.
pvresize /dev/xvdb
pvdisplay
Alloc PE / Size 8191 / 32.00 GiB
Free PE / Size 8192 / 32.00 GiB
Было 32, стало 64. Нормально.
Теперь надо увеличить наш том
# lvextend -l +100%FREE /dev/vg-www/www
Extending logical volume www to 64.00 GiB
Logical volume www successfully resized
И файловую систему.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg-www/www' first.
# e2fsck -f /dev/vg-www/www
...
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg-www/www to 16776192 (4k) blocks.
С первого запуска не прошло - надо сначала проверить раздел.
Всё, можно монтировать и работать.
Можно попробовать ptmax, но не совсем понятно, в какое место ей тыкать.
Надо выжать из саппорта селектела их вариант без перезагрузки, пока у меня не получилось.
Имеем: отдельный диск под /var/www, расположенный на диске /dev/xvdb, целиком отданным под lvm, с именем vg--www-www (группа vg-www, имя www), путь /dev/vg-www/www
Вариант с выключением для изменения размера -- вменяемых описаний, как это делать без перезагрузки, пока не найдено. Есть дока, но по ней не получилось.
Размер в панели уже увеличен.
Для начала, надо будет отмонтировать раздел. (umount)
Смотрим где наш том
pvdisplay
Растянем на весь новый диск.
pvresize /dev/xvdb
pvdisplay
Alloc PE / Size 8191 / 32.00 GiB
Free PE / Size 8192 / 32.00 GiB
Было 32, стало 64. Нормально.
Теперь надо увеличить наш том
# lvextend -l +100%FREE /dev/vg-www/www
Extending logical volume www to 64.00 GiB
Logical volume www successfully resized
И файловую систему.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg-www/www' first.
# e2fsck -f /dev/vg-www/www
...
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg-www/www to 16776192 (4k) blocks.
С первого запуска не прошло - надо сначала проверить раздел.
Всё, можно монтировать и работать.
Можно попробовать ptmax, но не совсем понятно, в какое место ей тыкать.
Надо выжать из саппорта селектела их вариант без перезагрузки, пока у меня не получилось.
суббота, 18 августа 2012 г.
Очередная авария в selectel
В 19.10 сегодня (17.08) произошел сбой:
"К сожалению, случилась авария со связностью в сети облака, мы работаем над её устранением. Пострадавшие машины будут перезагружены.
Потерь данных не прогнозируется. "
Видимо, хваленое дублированное СХД не помогло.
До сих пор (18.08, 00:20):
"Пострадавшие виртуальные машины запускаются. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. "
и
"Пострадавшие виртуальные машины запускаются. В результате ошибочной коммутации часть хранилищ оказалась отключенной от хостов виртуализации. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. Компенсация за даунтайм будет предоставлена в начале следующего месяца. Приносим извинения за созданные проблемы. "
"К сожалению, случилась авария со связностью в сети облака, мы работаем над её устранением. Пострадавшие машины будут перезагружены.
Потерь данных не прогнозируется. "
Видимо, хваленое дублированное СХД не помогло.
До сих пор (18.08, 00:20):
"Пострадавшие виртуальные машины запускаются. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. "
и
"Пострадавшие виртуальные машины запускаются. В результате ошибочной коммутации часть хранилищ оказалась отключенной от хостов виртуализации. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. Компенсация за даунтайм будет предоставлена в начале следующего месяца. Приносим извинения за созданные проблемы. "
вторник, 26 июня 2012 г.
selectel: лимиты облака
"Вы достигли ограничения по-умолчанию на количество виртуальных машин в облаке."
Оказалось, лимиты в облаке selectel - 11 вирт машин. Но можно написать запрос, и лимит увеличат.
"Лимиты введены по соображениям безопасности и рационального использования ресурсов. Эта мера помогает быстро отсеивать недобросовестных пользователей генерирующих мусорный трафик или распространяющих зловреды."
К каждой машине может быть подключено не более 15 дисков. Лимит диска 1.7Тб.
Уменьшению не подлежит. Изменение размеров только на отключенном диске/выключенной системе.
http://habrahabr.ru/company/selectel/blog/117969/
Оказалось, лимиты в облаке selectel - 11 вирт машин. Но можно написать запрос, и лимит увеличат.
"Лимиты введены по соображениям безопасности и рационального использования ресурсов. Эта мера помогает быстро отсеивать недобросовестных пользователей генерирующих мусорный трафик или распространяющих зловреды."
К каждой машине может быть подключено не более 15 дисков. Лимит диска 1.7Тб.
Уменьшению не подлежит. Изменение размеров только на отключенном диске/выключенной системе.
http://habrahabr.ru/company/selectel/blog/117969/
воскресенье, 26 февраля 2012 г.
Обновление облачного сервера на centos
Захотели обновить софт на серверах, стоящих в селектеле. Был centos 5.5
Простое обновление через yum update не удастся: нельзя обновить ядро
Поэтому надо обновить через
yum -x kernel-xen update
Замечание:
Не забываем, что для корректного автообновления надо иметь установленный yum-priorities
проверить:
# rpm -qa|grep -i prior
установить:
# yum install yum-priorities
Простое обновление через yum update не удастся: нельзя обновить ядро
Error Summary ------------- Disk Requirements: At least 101MB needed on the /lib/modules filesystem.
Поэтому надо обновить через
yum -x kernel-xen update
Замечание:
Не забываем, что для корректного автообновления надо иметь установленный yum-priorities
проверить:
# rpm -qa|grep -i prior
установить:
# yum install yum-priorities
пятница, 14 октября 2011 г.
selectel псевдо-API
Ответ саппорта
API на сегодняшний день в разработке, не реализован.
Для включения и выключения виртуальных машин существует workaround:
Последовательность действий:
1) Авторизация на сайте, получение и сохранение cookie:
curl -v --cookie-jar /tmp/cloud.txt --data "action_method=GET&user=ЛОГИН&pass=ПАРОЛЬ" https://support.selectel.ru/
2) Непосредственно команда для запуска машины:
curl -v --cookie /tmp/cloud.txt "https://support.selectel.ru/cloud/proxy.php?uuid=ИДЕНТИФИКАТОР_МАШИНЫ&action=vm-start";;;
3) Удаление cookie:
rm /tmp/cloud.txt
Идентификатор (VM UUID) указан на вкладке «Информация» виртуальной машины. Для выключения машины вместо действия (action) vm-start нужно написать vm-stop.
API на сегодняшний день в разработке, не реализован.
Для включения и выключения виртуальных машин существует workaround:
Последовательность действий:
1) Авторизация на сайте, получение и сохранение cookie:
curl -v --cookie-jar /tmp/cloud.txt --data "action_method=GET&user=ЛОГИН&pass=ПАРОЛЬ" https://support.selectel.ru/
2) Непосредственно команда для запуска машины:
curl -v --cookie /tmp/cloud.txt "https://support.selectel.ru/cloud/proxy.php?uuid=ИДЕНТИФИКАТОР_МАШИНЫ&action=vm-start";;;
3) Удаление cookie:
rm /tmp/cloud.txt
Идентификатор (VM UUID) указан на вкладке «Информация» виртуальной машины. Для выключения машины вместо действия (action) vm-start нужно написать vm-stop.
Подписаться на:
Сообщения (Atom)