UPDATE!
Вылечили без перезагрузки, ребята!
root@srv37.vpsville.ru# /etc/init.d/ntp stop
root@srv37.vpsville.ru# date
Sun Jul 1 13:09:45 MSK 2012
root@srv37vpsville.ru# date `date +"%m%d%H%M%C%y.%S"`
root@srv37vpsville.ru# date
Sun Jul 1 13:09:51 MSK 2012
Подтверждаю проблему. На двух из 1000 серверов (примечательно что оба с явой) вылетела проблема.
Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
Живет под Load Average 40.
Мы занимаемся в основном практикой телекома и зарабатыванием денег. На теорию, к сожалению, времени остается очень мало.
Лимит количества открытых TCP соединений — 65536.
Почему?
Отвечаю: Порты. В Линуксе 16 бит всего на все порты, включая входящие соединения.
Обычно это решается созданием алиасов на интерфейсах и того же roundrobin (по ряду причин такой вариант не подходил). Наше решение довольно красво.
Использовали wowza и нагрузка на процессор не доставила таких неудобств, как стоимость канала.
10 Gb/s у нас стоят как самолет.
Вообще, онлайн-вещание — это весело. Нагрузки большие, неизведанных проблем масса.
Как раз недавно закончили проект по доставке видео-контента на игровые площадки.
Поставили
а) 5 серверов с гигабитными каналом, SATA–III дисками, камнем с 9000 по cpubenchmark
б) сервер с E3-1275 для декодирования видео
в) региональный сервер рестрима.
г) веб сервер (nginx + php как cgi, apache бы копыта отбросил в первую минуту стрима) с флеш–клиентом, чатом и счетчиком посещений.
Итого — 8 серверов для 5Гб/с.
Дальше roundrobin в DNS. С веб сервера клиенты nginx'ом забирают плеер, в то время как один из серверов с гигабитом рестримит картинку всем.
— Специфичное железо оказалось несовместимым с 2.6.32 ядром, перекатились на 3.2.0 из бэкпортов.
— На третьем ядре стал грузиться drm. Пришлось выкинуть его в блэклист.
— Под нагрузкой отвалился r8169, пришлось ставить r8168.
— Прогнали iperf, замерили каждый сервер с учетом утилизации порта гигабит, но не догадались, что серваки с гигабитными портами воткнули в свич с гигабитным аплинком. Это, конечно, был провал. Очень быстро сообразили, переткнули.
— Затем под нагрузкой переполнилась таблица для хранения записей соединений и начал лететь nf_conntrack: table full, dropping packet, пофиксили.
— Дали стрим на весь канал и на web сервере ON–AIR оказалась около 4.000 и прогнулся web сервер, установивший лимит соединений. То есть, коннектится клиент, он поднимает соединения и не может закрыть их 60 секунд. Тупо netstat –na | wc –l = 65.000 и приехали. Больше не будет никогда, sysctl не поможет. Пересобрали ядро, понизив порог TIME_WAIT и сайт взлетел.
Ну и с десяток мелких тонкостей еще было, sysctl перековыряли как следует.
Над тюнингом вовзы и самим плеером также ребята трудились. Сейчас вполне все бегает и в месяц раздает под 100ТБ траффика.
Дебиан 6 с 4-м ксеном вышел в том году, до этого уже должна была быть готовая архитектура.
Вы врядли работали на дебиане 5-м ибо там были патчи от OpenSUSE, логичнее предположить что это была CentOS с 2.6.18 или OpenSUSE как у Скалакси.
Как будете обновлять старые хост-системы?
Если оперативки много, томиграция может подвесить машину.
La ололо как прыгает при живой миграции.
А вы дожидаться стабильных обновлений не будете? Зачем патчить-то
Отмечу, что в отличие от зимней чудовищной проблемы sg_dd гипервизора KVM, когда эксплоит был доступен сразу и позволял уничтожить все данные на кластере с одной виртуальной машины, для XEN эксплоита еще нет, а первые патчи уже появились.
Я ответил на фразу А так по ходу дела надежный один Амазон
вот этим habrahabr.ru/post/117933/
Надежность, близкую к 99.99% можно получить. Но вопрос в цене. Глупо ожидать за 1.000 рублей непадающий сервис. Вы бы знали сколько всего накручено у облака: железо, гипервизоры, управлялка, CLVM, ISCSI, DRBD, OpenStack и каждый элемент может дать отказ. Помимо того, что квалификация людей, работающих с этими системами, как правило, очень высокая. Это нестандартные сервисы, по которым мануалов куча. Практически все баги ловятся самостоятельно и просить помощи в расшифровке логов у гугла тяжело.
Амазон, кстати один из самыъх дорогих облаков, насколько я знаю.
Я тут ждал…
А Вашей статьей Вы только подтвердили, что selinux по дефолту надо выключать, ибо он несет много проблем при настройке ПО, а толку без настройки 0.
Кому надо, пусть настраивают.
Мы тоже работаем с ксеном 4 года. Не в таких промышленных масштабах как Вы, но около 30-40 хост-систем с ~25 виртуальных машин на каждой имеется.
Баги встречаются и «самостоятельно устранять» — это самое интересное. Вы преподнесли статью как готовую HowTo, преподнеся как готовое стабильное решение, а самое интересное не написали. Какие баги возникли при остановке доменов XEN и как пофиксили?
Верификация бэкапа — это важнейший момент. Вы его упускаете.
При активной работе с LVM снапшотами наблюдается не деградация проивзодительности, а полный отказ системы. (Был эксперимент по запуску корневого раздела машин на снапшотах)
А без ntp Вы зря, время надо подкручивать.
Вылечили без перезагрузки, ребята!
root@srv37.vpsville.ru# /etc/init.d/ntp stop root@srv37.vpsville.ru# date Sun Jul 1 13:09:45 MSK 2012 root@srv37vpsville.ru# date `date +"%m%d%H%M%C%y.%S"` root@srv37vpsville.ru# date Sun Jul 1 13:09:51 MSK 2012Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
Живет под Load Average 40.
vpsville.ru XEN
fastvps.ru OpenVZ
Лимит количества открытых TCP соединений — 65536.
Почему?
Отвечаю: Порты. В Линуксе 16 бит всего на все порты, включая входящие соединения.
Обычно это решается созданием алиасов на интерфейсах и того же roundrobin (по ряду причин такой вариант не подходил). Наше решение довольно красво.
10 Gb/s у нас стоят как самолет.
Вообще, онлайн-вещание — это весело. Нагрузки большие, неизведанных проблем масса.
Как раз недавно закончили проект по доставке видео-контента на игровые площадки.
Поставили
а) 5 серверов с гигабитными каналом, SATA–III дисками, камнем с 9000 по cpubenchmark
б) сервер с E3-1275 для декодирования видео
в) региональный сервер рестрима.
г) веб сервер (nginx + php как cgi, apache бы копыта отбросил в первую минуту стрима) с флеш–клиентом, чатом и счетчиком посещений.
Итого — 8 серверов для 5Гб/с.
Дальше roundrobin в DNS. С веб сервера клиенты nginx'ом забирают плеер, в то время как один из серверов с гигабитом рестримит картинку всем.
— Специфичное железо оказалось несовместимым с 2.6.32 ядром, перекатились на 3.2.0 из бэкпортов.
— На третьем ядре стал грузиться drm. Пришлось выкинуть его в блэклист.
— Под нагрузкой отвалился r8169, пришлось ставить r8168.
— Прогнали iperf, замерили каждый сервер с учетом утилизации порта гигабит, но не догадались, что серваки с гигабитными портами воткнули в свич с гигабитным аплинком. Это, конечно, был провал. Очень быстро сообразили, переткнули.
— Затем под нагрузкой переполнилась таблица для хранения записей соединений и начал лететь nf_conntrack: table full, dropping packet, пофиксили.
— Дали стрим на весь канал и на web сервере ON–AIR оказалась около 4.000 и прогнулся web сервер, установивший лимит соединений. То есть, коннектится клиент, он поднимает соединения и не может закрыть их 60 секунд. Тупо netstat –na | wc –l = 65.000 и приехали. Больше не будет никогда, sysctl не поможет. Пересобрали ядро, понизив порог TIME_WAIT и сайт взлетел.
Ну и с десяток мелких тонкостей еще было, sysctl перековыряли как следует.
Над тюнингом вовзы и самим плеером также ребята трудились. Сейчас вполне все бегает и в месяц раздает под 100ТБ траффика.
Вы врядли работали на дебиане 5-м ибо там были патчи от OpenSUSE, логичнее предположить что это была CentOS с 2.6.18 или OpenSUSE как у Скалакси.
Как будете обновлять старые хост-системы?
La ололо как прыгает при живой миграции.
А вы дожидаться стабильных обновлений не будете? Зачем патчить-то
надежный один Амазон
вот этим habrahabr.ru/post/117933/
Надежность, близкую к 99.99% можно получить. Но вопрос в цене. Глупо ожидать за 1.000 рублей непадающий сервис. Вы бы знали сколько всего накручено у облака: железо, гипервизоры, управлялка, CLVM, ISCSI, DRBD, OpenStack и каждый элемент может дать отказ. Помимо того, что квалификация людей, работающих с этими системами, как правило, очень высокая. Это нестандартные сервисы, по которым мануалов куча. Практически все баги ловятся самостоятельно и просить помощи в расшифровке логов у гугла тяжело.
Амазон, кстати один из самыъх дорогих облаков, насколько я знаю.
А Вашей статьей Вы только подтвердили, что selinux по дефолту надо выключать, ибо он несет много проблем при настройке ПО, а толку без настройки 0.
Кому надо, пусть настраивают.
Баги встречаются и «самостоятельно устранять» — это самое интересное. Вы преподнесли статью как готовую HowTo, преподнеся как готовое стабильное решение, а самое интересное не написали. Какие баги возникли при остановке доменов XEN и как пофиксили?
Верификация бэкапа — это важнейший момент. Вы его упускаете.
При активной работе с LVM снапшотами наблюдается не деградация проивзодительности, а полный отказ системы. (Был эксперимент по запуску корневого раздела машин на снапшотах)