- Сколько будет стоить аренда канала 1Гбит для выделенного сервера (без учёта стоимость аренды сервера)?
- Месячная аренда канала в 1 Гбит/с для выделенного сервера составляет 90000 рублей.
- Судя по новости http://selectel.ru/news/increasing-network-connection-speed-to-100mbits/ - если я закажу 9 самых дешёвых серверов и не буду использовать их, то получу 1Гбит за 13500 руб. Так?
- Если на Вашем аккаунте есть 10 заказанных серверов, то Вы можете запросить смену учета трафика. После чего да, Вы сможете использовать 1 Гбит/c на все 10 серверов или 1 в отдельности.
админские истории
Подписчиков:
70Постов:
23Что-то в последнее время у меня слишком много админских событий, что не очень радует... не люблю я нервничать.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
узнал тут, что двач уже три дня лежит (и будет ещё лежать до утра как минимум). Причина:
храните бэкапы на выделенных серверах, тащемта. новехонькие 2 из 4х 300-гиговых SAS дисков, по предварительной информации могли пиздануться.
Да ещё и дальше пишет "макаки из Лизвеба заменили 4 из 4 дисков в рейде 5. разворачиваем бэкапы".
Бггг. То есть, он использует крутые SAS, но не хватает денег даже raid1 собрать =)
храните бэкапы на выделенных серверах, тащемта. новехонькие 2 из 4х 300-гиговых SAS дисков, по предварительной информации могли пиздануться.
Да ещё и дальше пишет "макаки из Лизвеба заменили 4 из 4 дисков в рейде 5. разворачиваем бэкапы".
Бггг. То есть, он использует крутые SAS, но не хватает денег даже raid1 собрать =)
Картиночный сервер, где хранятся и обрабатываются все картинки, начал глючить. Раз-два в неделю зависает так, что даже автоматический резет не помогал. Похоже проблема хардварная. В хетцнере это решается просто - отдаёшь сервер им на диагностику на 12 часов. Делать неработающими картинки на 12 часов не очень хотелось. Поэтому надо было перенести его на другой сервер.
Но тут я подумал - у меня, включая картиночный, уже есть 4. На трёх диски не загружены почти. Память есть. В основном используется процессор для отдачи php. Почему бы не сделать какую-нибудь кластерную фс и убрать одну из точек отказа? Тогда все сервера с апачем будут равноправными, все вместе писать/читать с этой фс и всё будет збс.
Посмотрел какие есть кластерные фс. Самая крутая - ceph. Уже год как вышли из беты. Пишут, что офигенно быстрая и надёжная. Самовосстанавливается, нет одной точки отказа. В будущем можно просто подключать к ней жёсткие диски и она всё будут перебалансировать.
Придумано - сделано. Код на php быстро подправил: ломать - не строить. По сути надо было сломать весь код, который отвечал за перенаправление картиночных запросов на картиночный сервер.
Поставил ceph. Во время установки удивило, что они полностью тестируют только на убунте с дефолтным ядром 3.2, но рекомендуют обязательно обновляться до ядра 3.4/3.6, ибо на более ранних версиях у них не работают серверные модули о_О. Ядро 3.6 и "стабильность" у меня в глове не укладывались, но можно было всё сделать и без модулей ядра. Поэтому ceph был успешно установлен и подмонтирован.
С первого взгляда, всё было хорошо. Есть на одном сервере создать файл, то он появлялся на другом сервере.
И тут я совершил роковую ошибку. Я доверился их заявлениям о скорости/стабильности и переключил сервера на использование ceph.
продолжение следует...
Но тут я подумал - у меня, включая картиночный, уже есть 4. На трёх диски не загружены почти. Память есть. В основном используется процессор для отдачи php. Почему бы не сделать какую-нибудь кластерную фс и убрать одну из точек отказа? Тогда все сервера с апачем будут равноправными, все вместе писать/читать с этой фс и всё будет збс.
Посмотрел какие есть кластерные фс. Самая крутая - ceph. Уже год как вышли из беты. Пишут, что офигенно быстрая и надёжная. Самовосстанавливается, нет одной точки отказа. В будущем можно просто подключать к ней жёсткие диски и она всё будут перебалансировать.
Придумано - сделано. Код на php быстро подправил: ломать - не строить. По сути надо было сломать весь код, который отвечал за перенаправление картиночных запросов на картиночный сервер.
Поставил ceph. Во время установки удивило, что они полностью тестируют только на убунте с дефолтным ядром 3.2, но рекомендуют обязательно обновляться до ядра 3.4/3.6, ибо на более ранних версиях у них не работают серверные модули о_О. Ядро 3.6 и "стабильность" у меня в глове не укладывались, но можно было всё сделать и без модулей ядра. Поэтому ceph был успешно установлен и подмонтирован.
С первого взгляда, всё было хорошо. Есть на одном сервере создать файл, то он появлялся на другом сервере.
И тут я совершил роковую ошибку. Я доверился их заявлениям о скорости/стабильности и переключил сервера на использование ceph.
продолжение следует...
итак, в пятницу я начал разносить nginx на две части, как я писал в предыдущем топике. После разнесения стало заметно меньше лагов. И вдруг сильно подскочило количество просмотров на посетителя. В картинке ниже - пример того, что было в воскресение по сравнению с субботой.
продолжение под катом
продолжение под катом
Расскажу о вчерашних моих изысканиях.
Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит nginx), там на сервере большой кэш картинок. То, что нет в кэше картинок и хтмл-страницы отправляются на один из бэкэндов.
Симптомы: время от времени весь nginx подвисает на 1-3 секунды.
Проблема: nginx читает с жёсткого диска данные и из-за сильной пиковой нагрузки на диск его блокирует на время чтения. Вот пример strace:
20:38:49.834933 open("/mnt/ssd/joyreactor/d4/9c/c2a4cb245d73e4c6b348ad8f73769cd4", O_RDONLY|O_NONBLOCK) = 2351
...snip...
20:38:51.883163 pread(2351, "E\244\232\241"..., 32768, 4194650) = 32768
20:39:05.764386 --- SIGALRM (Alarm clock) @ 0 (0) ---
Можно видеть,что файл открывается с флагом O_NONBLOCK - то есть, чтение должно быть не блокирующее. И при запуске этого неблокирующего чтения, тред блокируется на 15 секунд - с 20:38:51 до 20:39:05
Лезу в поиск. Нахожу, что "не блокирующий" в терминах линукса вполне может быть заблокирован на любое количество времени. Он не блокируется от всяких локов. А от сильной нагрузки на хард - вполне себе блокируется. Но есть асинхронное i/o (AIO). Это ахуенно продвинутая вещь и была реализована в линуксе пару лет назад! Позволяет делать запросы к диску полностью без блокировок. Но при этом не используются никакие дисковые кэши. То есть, надо в программе реализовывать всю дисковую подсистему, если хочешь работать с этим AIO. Заебись! Но нахуй такое нужно? Всё просто - эту систему реализовывали прогеры из IBM и Oracle. Они её делали для СУБД. А в СУБД итак дисковая подсистема своя написана и они на хард пишут напрямую.
А теперь самое интересное - во FreeBSD эта фича была реализована по-нормальному с кэшами в версии 4.3. Эта версия была выпущена 20 Апреля 2001 года... и нафиг я 7 лет назад с бзди пересаживался на линукс?!
Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит nginx), там на сервере большой кэш картинок. То, что нет в кэше картинок и хтмл-страницы отправляются на один из бэкэндов.
Симптомы: время от времени весь nginx подвисает на 1-3 секунды.
Проблема: nginx читает с жёсткого диска данные и из-за сильной пиковой нагрузки на диск его блокирует на время чтения. Вот пример strace:
20:38:49.834933 open("/mnt/ssd/joyreactor/d4/9c/c2a4cb245d73e4c6b348ad8f73769cd4", O_RDONLY|O_NONBLOCK) = 2351
...snip...
20:38:51.883163 pread(2351, "E\244\232\241"..., 32768, 4194650) = 32768
20:39:05.764386 --- SIGALRM (Alarm clock) @ 0 (0) ---
Можно видеть,что файл открывается с флагом O_NONBLOCK - то есть, чтение должно быть не блокирующее. И при запуске этого неблокирующего чтения, тред блокируется на 15 секунд - с 20:38:51 до 20:39:05
Лезу в поиск. Нахожу, что "не блокирующий" в терминах линукса вполне может быть заблокирован на любое количество времени. Он не блокируется от всяких локов. А от сильной нагрузки на хард - вполне себе блокируется. Но есть асинхронное i/o (AIO). Это ахуенно продвинутая вещь и была реализована в линуксе пару лет назад! Позволяет делать запросы к диску полностью без блокировок. Но при этом не используются никакие дисковые кэши. То есть, надо в программе реализовывать всю дисковую подсистему, если хочешь работать с этим AIO. Заебись! Но нахуй такое нужно? Всё просто - эту систему реализовывали прогеры из IBM и Oracle. Они её делали для СУБД. А в СУБД итак дисковая подсистема своя написана и они на хард пишут напрямую.
А теперь самое интересное - во FreeBSD эта фича была реализована по-нормальному с кэшами в версии 4.3. Эта версия была выпущена 20 Апреля 2001 года... и нафиг я 7 лет назад с бзди пересаживался на линукс?!
Следующая история про работу с cloudflare.
Как-то раз hetzner заблокировал основной ip реактора из-за того, что на него идёт ddos. Причём сделал это в пятницу вечером, а разблокировать собирался в лучшем случае в понедельник утром. Я повозмущался немного, но потом вычитал, что стандартные хостеры просто не расчитаны на такие сетевые нагрузки. Поэтому было решено фронтенд вынести куда-нибудь на специализированный хостинг.
Есть куча анти-ддос хостеров. Но они дороговато стоят. И тут я вспомнил про cloudflare. Про них раньше писали много отрицательных отзывов, но с тех пор прошло много времени. Да и всякие двачи на них сидят. Решили сразу платный аккаунт брать за 200$ - там есть priority support и защита от ddos.
1) где-то в 19:00 меняю dns на них
2) в 21:00 начинаю наблюдать, что количество пользователей уменьшается.
3) тут связывается со мной Zubo и говорит, что реактор открывается только через тор. Говорю ему какие команды запускать. Выясняем, что с его провайдера (а у него какой-то московский крупный) не резолвятся их ns-сервера.
4) в 21:30 пишу им о том, что наблюдаем проблемы и прикладываю все трейсы, из которых видно, что Zubo не может подключиться к их ns-серверам.
5) в 23:30 падение трафика более 20%. От них - ни весточки. Я меняю ns-сервера обратно.
6) в 3:00 трафик возвращается.
7) в 11:00 от них приходит письмо "ой, а вы уже сменили ns-ы у себя? ну тогда мы не можем ничем помочь. Теперь уже не понять, в чём проблема"
При более внимательном прочтении их планов оплаты обнаруживаю, что саппорт 24/7 они дают только для самого крутого варианта - который от 3000$/месяц. За такие деньги можно купить профессиональный анти-ддос хостинг.
вот замечательный топик по тому же поводу - http://blog.kuzmitch.ru/2012/07/cdn-cloudflare.html
Там в комментах спрашивают - почему же автор через 3 месяца уже ушёл от cloudflare. И он отвечает - что есть куча проблем, но если бы платные были, то наверное этих проблем бы небыло. Так вот - эти проблемы у них независимо от того, сколько им платишь =)
Как-то раз hetzner заблокировал основной ip реактора из-за того, что на него идёт ddos. Причём сделал это в пятницу вечером, а разблокировать собирался в лучшем случае в понедельник утром. Я повозмущался немного, но потом вычитал, что стандартные хостеры просто не расчитаны на такие сетевые нагрузки. Поэтому было решено фронтенд вынести куда-нибудь на специализированный хостинг.
Есть куча анти-ддос хостеров. Но они дороговато стоят. И тут я вспомнил про cloudflare. Про них раньше писали много отрицательных отзывов, но с тех пор прошло много времени. Да и всякие двачи на них сидят. Решили сразу платный аккаунт брать за 200$ - там есть priority support и защита от ddos.
1) где-то в 19:00 меняю dns на них
2) в 21:00 начинаю наблюдать, что количество пользователей уменьшается.
3) тут связывается со мной Zubo и говорит, что реактор открывается только через тор. Говорю ему какие команды запускать. Выясняем, что с его провайдера (а у него какой-то московский крупный) не резолвятся их ns-сервера.
4) в 21:30 пишу им о том, что наблюдаем проблемы и прикладываю все трейсы, из которых видно, что Zubo не может подключиться к их ns-серверам.
5) в 23:30 падение трафика более 20%. От них - ни весточки. Я меняю ns-сервера обратно.
6) в 3:00 трафик возвращается.
7) в 11:00 от них приходит письмо "ой, а вы уже сменили ns-ы у себя? ну тогда мы не можем ничем помочь. Теперь уже не понять, в чём проблема"
При более внимательном прочтении их планов оплаты обнаруживаю, что саппорт 24/7 они дают только для самого крутого варианта - который от 3000$/месяц. За такие деньги можно купить профессиональный анти-ддос хостинг.
вот замечательный топик по тому же поводу - http://blog.kuzmitch.ru/2012/07/cdn-cloudflare.html
Там в комментах спрашивают - почему же автор через 3 месяца уже ушёл от cloudflare. И он отвечает - что есть куча проблем, но если бы платные были, то наверное этих проблем бы небыло. Так вот - эти проблемы у них независимо от того, сколько им платишь =)
следующая история про неудавшийся ддос.
В рамках подготовки к задаче по переносу обработки картинок на другой сервер (см предыдущий пост), надо было стереть кэш memcached. Раньше это было достаточно болезненно, ибо mysql захлёбывался от количества запросов. Но сейчас мемкэшов стало два и можно было перегружать их по одному - удаляя по половине кэша. Таким образом нагрузка была меньше.
Ну встал пораньше и в 10 утра перегрузил по очереди кэши. Вроде всё хорошо с первым пиком сервера успешно справились. Дальше нагрузка всё равно немного больше - процентов на 20%. Они пару дней будут наполняться менее популярными страницами, куда заходят, но не часто.
Через пару часов проверяю нагрузку. Обнаруживаю что она выше, чем должна быть. Первая мысть - где-то напортачил с кэшами и они не подцепились. Тогда ещё через час сервера умрут по естественной нагрузкой. Смотрю запросы в мускуле - и вправду, идёт много запросов, которые должны быть жёстко закэшированны. И тут же понимаю, что если бы кэши полностью не подцепились, то сервера бы уже умерли. А тут скоро уже пиковая нагрузка, а им вполне нормально, хоть и выше нормы.
Долго размышляю и изучаю данную проблему. На всякий случай, перегружаю апачи. Ничего не меняется. Иду мыться в душ и там меня осеняет. Симфони (да и большниство серверов) не кэшируют POST-запросы. Наверное где-то есть страница, которая грузится через POST. Возвращаюсь и обнаруживаю в логах примерно такое:
85.26.241.3 - - [30/Jan/2013:05:09:14 +0100] "POST /tag/mass%2Beffect/new/11?count=&1359518948806.76 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
85.26.241.3 - - [30/Jan/2013:05:13:38 +0100] "POST /post/204783?count=&1359519213127.96 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
В гугле находит, что heias - это какая-то адвара. Похоже ещё и система управление ддосом. Они слали специально запросы, которые пробиывают кэш. Проверка на тип запроса у меня не везде проводилась и в некоторых местах оно пробивалось. Правда результат был всё равно плачевный для них - если бы я не мониторил специально нагрузку, то никто бы и не заметил этого ддоса. Им надо было создать хотя бы 20% от естественной посещалки реактора, чтобы пробивка кэша дала результаты.
Сейчас погрепал в логах - они нашли ещё пару мест, где не проверяется GET/POST. Надо будет поправить для чистоты кода.
В рамках подготовки к задаче по переносу обработки картинок на другой сервер (см предыдущий пост), надо было стереть кэш memcached. Раньше это было достаточно болезненно, ибо mysql захлёбывался от количества запросов. Но сейчас мемкэшов стало два и можно было перегружать их по одному - удаляя по половине кэша. Таким образом нагрузка была меньше.
Ну встал пораньше и в 10 утра перегрузил по очереди кэши. Вроде всё хорошо с первым пиком сервера успешно справились. Дальше нагрузка всё равно немного больше - процентов на 20%. Они пару дней будут наполняться менее популярными страницами, куда заходят, но не часто.
Через пару часов проверяю нагрузку. Обнаруживаю что она выше, чем должна быть. Первая мысть - где-то напортачил с кэшами и они не подцепились. Тогда ещё через час сервера умрут по естественной нагрузкой. Смотрю запросы в мускуле - и вправду, идёт много запросов, которые должны быть жёстко закэшированны. И тут же понимаю, что если бы кэши полностью не подцепились, то сервера бы уже умерли. А тут скоро уже пиковая нагрузка, а им вполне нормально, хоть и выше нормы.
Долго размышляю и изучаю данную проблему. На всякий случай, перегружаю апачи. Ничего не меняется. Иду мыться в душ и там меня осеняет. Симфони (да и большниство серверов) не кэшируют POST-запросы. Наверное где-то есть страница, которая грузится через POST. Возвращаюсь и обнаруживаю в логах примерно такое:
85.26.241.3 - - [30/Jan/2013:05:09:14 +0100] "POST /tag/mass%2Beffect/new/11?count=&1359518948806.76 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
85.26.241.3 - - [30/Jan/2013:05:13:38 +0100] "POST /post/204783?count=&1359519213127.96 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
В гугле находит, что heias - это какая-то адвара. Похоже ещё и система управление ддосом. Они слали специально запросы, которые пробиывают кэш. Проверка на тип запроса у меня не везде проводилась и в некоторых местах оно пробивалось. Правда результат был всё равно плачевный для них - если бы я не мониторил специально нагрузку, то никто бы и не заметил этого ддоса. Им надо было создать хотя бы 20% от естественной посещалки реактора, чтобы пробивка кэша дала результаты.
Сейчас погрепал в логах - они нашли ещё пару мест, где не проверяется GET/POST. Надо будет поправить для чистоты кода.
Буду писать тут интересные случае из работы.
Для начала - почему вчера весь день тормозил реактор. Уже давно основной фронтэнд сдыхал. На нём же обрабатывались картинок и он не справлялся с отдачей картинок на скорости 2Гбит и обработкой их. Поэтому я начал потихоньку обработку картинок переносить в другое место.
И вдруг произошло что-то. Симптомы:
1) на сата дисках чтение 5Mb/s
2) на ссд диске запись только 0.5Mb/s. Хотя должна быть те же 5Mb/s, ибо всё что читается с сата потом сразу кладётся в кэш ссд.
3) запросы время от времени подвисают на 5-10-15 секунд. Причём в них нет никакого криминала - обычная отдача малоиспользующейся картинки размеров в 500Кб.
Начал грешить на nginx - что он почему-то не записывает в кэш то, что отдаёт бэкэнд. Долго мучался - ничего не смог выяснить. Решил раньше времени переносить на новый сервер бэкэнд - должно хотя бы распределить нагрузку.
Во время rsync понял в чём проблема была - все картинки у меня складываются в одну директорию. И теперь она выглядит так:
drwxrwxrwx 2 root root 59M Jan 30 19:58 pics
Можно заметить, что размер директории - 59Мб. Похоже из-за возросшей нагрузки она вытеснялась из файлового кэша и очередной запрос на 500Кб хотел открыть эту директорию, что заставляло его читать все 59Мб и тормозить всю систему.
Для начала - почему вчера весь день тормозил реактор. Уже давно основной фронтэнд сдыхал. На нём же обрабатывались картинок и он не справлялся с отдачей картинок на скорости 2Гбит и обработкой их. Поэтому я начал потихоньку обработку картинок переносить в другое место.
И вдруг произошло что-то. Симптомы:
1) на сата дисках чтение 5Mb/s
2) на ссд диске запись только 0.5Mb/s. Хотя должна быть те же 5Mb/s, ибо всё что читается с сата потом сразу кладётся в кэш ссд.
3) запросы время от времени подвисают на 5-10-15 секунд. Причём в них нет никакого криминала - обычная отдача малоиспользующейся картинки размеров в 500Кб.
Начал грешить на nginx - что он почему-то не записывает в кэш то, что отдаёт бэкэнд. Долго мучался - ничего не смог выяснить. Решил раньше времени переносить на новый сервер бэкэнд - должно хотя бы распределить нагрузку.
Во время rsync понял в чём проблема была - все картинки у меня складываются в одну директорию. И теперь она выглядит так:
drwxrwxrwx 2 root root 59M Jan 30 19:58 pics
Можно заметить, что размер директории - 59Мб. Похоже из-за возросшей нагрузки она вытеснялась из файлового кэша и очередной запрос на 500Кб хотел открыть эту директорию, что заставляло его читать все 59Мб и тормозить всю систему.
а вам знакомо чувство, когда запускаешь на рабочей базе биллинга c сотней тысяч клиентов запрос
UPDATE users SET money=money+100
и вдруг понимаешь, что забыл добавить WHERE id=... ?
UPDATE users SET money=money+100
и вдруг понимаешь, что забыл добавить WHERE id=... ?
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме админские истории (+23 постов - админские истории)
Модераторы тега
Наши любимые теги
Wapaper
artist
Подземелье Мраморных Врат
Комиксы
kurokimoko
Anime Artist
EGS халява
Epic Games Store
VanRipper
artist
BasedBinkie
artist
Топ комментов
А бывает, комменты лучше постов. Смотрим топ тредов и вникаем!