Давненько я не писал сюда... так всё хорошо было...
Всё началось 31 октября. Хостер, у которого находится основной фронтэнд, сказал что у него проблемы с провайдерами и будет технические работы. Некоторое время он просто лежал. Потом отрубился ipv6 (а по нему у меня общается фронтэнд и бэкэнд). Заметил я это похоже только через несколько часов. Как заметил - переключил их на ipv4 и реактор, наконец, заработал. Но по вечерам загрузка картинок реально тормозила. Хостер сказал, что починит всё "очень быстро" - за пару недель.
8го октября мы решили "Хватит это терпеть!". И я пошёл искать где бы ещё арендовать сервер в европе, тянущий 10Гбит и прокачивающий 0.5Пб трафика в месяц за копейки. Нашлось только 2 предложения:
- одно от достаточно хорошей компании Swiftway, но в 2 раза дороже и жёсткое ограничение по трафику - превышение 0.5Пб было дорогим. Хотя можно было подоговариваться по поводу превышения трафика.
- второе от британской redstation. Там предлагался безлимитный 1.5Гбит по цене моего сервера. У меня в среднем трафик 1.8Гбит и 95% burstable - 2.5 Гбит. Поэтому два сервера должны были вполне уместиться по трафику и иметь запас. Но дальше я начал расспрашивать их как они считают трафик и оказалось, что они жёстко шейпят на 1.5Гбит. А у реактора бывают кратковременные (и не очень) всплески сильно выше среднего. Поэтому тоже не очень
- третье предложение было от нашего же хостера. У него датацентров много. Проблемы только в одном. Почему бы не попробовать другие? Это и было принято за рабочее решение.
Оказалось, что в двух нормальных ДЦ - Вене и Праге - у него мест нет. Есть только в Злине - деревушке на востоке Чехии. Ну делать нечего - попробуем его. Оплатил. Всё поставили. Ipv6, как всегда, заработал с 3ьего раза у них. Попинговал разные места - по одному из маршрутов был небольшой пакетлост. Написал им - ответ мы скажем своему провайдеру, чтобы они увеличили канал в том месте, но когда они это сделают не знаем. Ладно, наверное что-то немного лагающее будет лучше чем сильно лагающее. Переключил реактор на сервер в Злине и начался пиздец. По вечерам пакетлост по всем направлениям, ещё хуже чем в лагающем Амстердаме.
А тут ещё и подходит время оплаты амстердамского сервера (который по прошестии 12 дней всё ещё тормозил). Пишу хостеру письмо, что нах вас всех, возвращайте деньги. После долгих бесед и валерьянки в форме коньяка, они мне подарили неделю амстердамсого сервера бесплатно, заверили что в течении этой недели всё починится, Злинский сервер отменили и вернули полностью деньги на внутренний счёт.
После такой недели у меня была только одна мысль - "Придётся это терпеть".
Протрезвев через пару дней ко мне пришла ещё одна мысль. Бэкэнды у реактора стоят у другого хостера. Там с каналами всё достаточно плохо, зато сервера дешёвые. И недавно они обновили линейку своих серверов. И теперь за 50 евро можно взять лучший сервер, чем у меня стоят за 60 евро. Только надо установочный платёж в размере 50евро заплатить. Вот я и решил - через 5 месяцев этот апгрейд всё равно окупится. Давай сделаю сейчас, на некоторое время старые всё ещё будут работать, а новые настрою на отдачу картинок. Тогда хотя бы немного разгружу амстердам и часть картинок будет отдаваться быстро. За неделю я не успею выбраться за лимиты трафика.
Сказано - сделано. Сделал всё это. Пару дней оно проработало в этом режиме и потом Амстердам починили, наконец. Вернее, основные лаги там пропали, но остались ещё небольшие по ipv4 и полностью не рабочий ipv6. Но это решаемо (сейчас вот решаю потихоньку).
И тут наступает другая проблема - перенос старых серверов на новые. Перенос я делал в попыхах (чтобы меньше платить за старые сервера) и в результате не все данные в свифте перенеслись. Заметили это только когда сервера уже забрали. В результате потерялись порядка 1-2% картинок. Из хороших новостей, что у меня одна и та же картинка хранится в куче разных вариантов - увеличенная, уменьшенная, с вотермарками и т.д. Сейчас восстанавливаю что возможно.
Вторую проблему вчера решал. Новые сервера нещадно жрали проц. Это при том, что он там на 2 поколения лучше, чем на старых. До полуночи дебажил всё это. Оказалось, что в libmemcached в последней версии сломали ipv6. Причём там был такой код:
#if 0
hints.ai_family= AF_INET;
#endif
Он никогда не работал. Но какой-то умный человек решил, что это наверное ошибка и удалил If/endif. Из-за этого строчка начала работать, а она запрещает использование ipv6. Ну сегодня нашёл предыдущую версию, накатил её на все серера, нагрузка сразу спала. Уф, хоть одна хорошая новость.
Надеюсь в следующей части я расскажу как сделал CDN, ибо уже давно жду, когда мне поставят 2ой фронтэнд в Нью-Йорке.
Результаты поиска потегуадминские истории
Дополнительные фильтры
Теги:
админские историиновый тег
Автор поста
Рейтинг поста:
-∞050100150200300400+
Найдено: 23
Сортировка:
сегодня (по московскому времени уже вечера) на главную вышла гифка размер 120Мб ( http://joyreactor.cc/post/807115 ). Вообще, её не легко туда пропихнуть - похоже чуваку повезло, что она обработалась быстрее, чем прошёл таймаут =). Мне стал интересен график трафика в связи с появлением этой гифки. Он ниже. Внимание, вопрос! Когда эта гифка вышла во Всё главной и когда она вышла в Хорошее? =)
После неудачной попытки с ceph и советов забить на это, как от гуру-школьников на реакторе, так и на хабре, я уже почти опустил руки.
В это время тестировался gfs2. Но он оказался: во-первых, плохо масштабируемым; во-вторых, достаточно медленным; в-третьих, ооочень сложным и глючным. Явно не расчитан на "commodity hardware".
Я пустился в размышления - почему же это так сложно и тормознуто. Ведь задача простая - хранить файл в нескольких копиях на разных серверах + как-нибудь сохранить где именно он хранится. При желании, это реализуется достаточно просто и быстро даже вручную.
И тут я понял основную ошибку - я искал файловую систему. А в ней не просто хранение, но ещё и система прав и лок файлов. Они мне не были нужны, поэтому я отказался от понятия файловой системы. И тут же обнаружил Openstack Swift. Это простое хранилище данных.
- Работает через REST-интерфейс (обычный http).
- В случае падения одной из нод, работает без проблем дальше.
- Используется в wikimedia для хранения всяких картинок.
В общем, проект достаточно зрелый. Хотя информации о нём достаточно мало - возможно из-за того, что для работы с ним надо менять код и вместо файловых методов использовать сетевые. Развернул, обнаружил несколько особенностей, которые не сильно повлияли на дальнейшие действия:
1) при большом количестве файлов, он может добавлять порядка 50 файлов в секунду. Для больших скоростей нужен ссд. Ну в обычное время у меня добавляется несколько файлов в минуту. Поэтому до этого предела ещё далеко.
2) полностью рабочая нода - это 15 разных демонов. Вначале немного охреневаешь от такого изобилия. Но со временем понимаешь, что всё чётко и стройно. Просто они, следуя философии unix, разделили разные функции на разные демоны. Во время первоначальной синхронизации, я отключил некоторые демоны и скорость возросла раза в два.
3) первоначальная заливка всего контента заняла порядка 2 недель неспешного копирования. Днём копирование отрубалось, чтобы не мешать реактору работать.
Итак, результаты:
1) уже 3 недели все новые картинки заливались в свифт. При чтении иногда они брались с диска, иногда - из свифта.
2) с начала этой недели картинки читались только из свифта. Они ещё писались на диск на всякий случай, но не читались
3) с сегодняшнего утра всё полностью перешло на свифт. На диск больше не пишется и не читается. В последний раз забэкаплю и на след.неделе удалю с боевых серверов.
Таким образом, я избавился от одной из трёх точек отказа. Ура!
Ну и всякие дополнительные мелочи:
1) во время переноса свифта обнаружил, что картиночный сервер упирается в канал 100Мбит в часы пик. Вовремя я начал чесаться по поводу его переноса... =)
2) следующая точка отказа, которую надо будет устранять, - mysql. Раньше думал, что придётся переходить на postgresql, ибо в мускуле всё плохо с репликацией, failover и вообще версия 5.5 (которая появилась после покупки ораклом) у них очень плохая вышла. Коммуна была расстроена и считала, что оракл убьёт мускуль. Но в феврале этого года вышла версия 5.6, которая удивительно хорошо работает - быстрее 5.5, добавлены фичи для репликации из коробки, для php выпустили плагин с load-balancing и failover. В общем, похоже мускуль воскрес из мёртвых и мне это нравится, ибо не хочется переучиваться на постгрю.
3) написал хостеру, что наблюдаю днём пакетлост 0.1%, а по вечерам наблюдаю пакет-лост 0.5%. На удивление, не послали нахрен, а начали разбираться. Хоть и достаточно вяло.
4) после того, как перешёл на swift, на серверах стало нехватать памяти (всего 16Гб). Пришлось перейти с apache на nginx+php-fpm. Из-за того, что фротэнд держал с бэкэндами keel-alive соединения, получил выигрыш в памяти в 3 раза - 300 Мб вместо 1Гб.
5) настроил себе в заббиксе красивые картинки. Теперь если что-то торимозит - я не бегаю по серверам, а запускаю один экран и всё сразу видно:
В это время тестировался gfs2. Но он оказался: во-первых, плохо масштабируемым; во-вторых, достаточно медленным; в-третьих, ооочень сложным и глючным. Явно не расчитан на "commodity hardware".
Я пустился в размышления - почему же это так сложно и тормознуто. Ведь задача простая - хранить файл в нескольких копиях на разных серверах + как-нибудь сохранить где именно он хранится. При желании, это реализуется достаточно просто и быстро даже вручную.
И тут я понял основную ошибку - я искал файловую систему. А в ней не просто хранение, но ещё и система прав и лок файлов. Они мне не были нужны, поэтому я отказался от понятия файловой системы. И тут же обнаружил Openstack Swift. Это простое хранилище данных.
- Работает через REST-интерфейс (обычный http).
- В случае падения одной из нод, работает без проблем дальше.
- Используется в wikimedia для хранения всяких картинок.
В общем, проект достаточно зрелый. Хотя информации о нём достаточно мало - возможно из-за того, что для работы с ним надо менять код и вместо файловых методов использовать сетевые. Развернул, обнаружил несколько особенностей, которые не сильно повлияли на дальнейшие действия:
1) при большом количестве файлов, он может добавлять порядка 50 файлов в секунду. Для больших скоростей нужен ссд. Ну в обычное время у меня добавляется несколько файлов в минуту. Поэтому до этого предела ещё далеко.
2) полностью рабочая нода - это 15 разных демонов. Вначале немного охреневаешь от такого изобилия. Но со временем понимаешь, что всё чётко и стройно. Просто они, следуя философии unix, разделили разные функции на разные демоны. Во время первоначальной синхронизации, я отключил некоторые демоны и скорость возросла раза в два.
3) первоначальная заливка всего контента заняла порядка 2 недель неспешного копирования. Днём копирование отрубалось, чтобы не мешать реактору работать.
Итак, результаты:
1) уже 3 недели все новые картинки заливались в свифт. При чтении иногда они брались с диска, иногда - из свифта.
2) с начала этой недели картинки читались только из свифта. Они ещё писались на диск на всякий случай, но не читались
3) с сегодняшнего утра всё полностью перешло на свифт. На диск больше не пишется и не читается. В последний раз забэкаплю и на след.неделе удалю с боевых серверов.
Таким образом, я избавился от одной из трёх точек отказа. Ура!
Ну и всякие дополнительные мелочи:
1) во время переноса свифта обнаружил, что картиночный сервер упирается в канал 100Мбит в часы пик. Вовремя я начал чесаться по поводу его переноса... =)
2) следующая точка отказа, которую надо будет устранять, - mysql. Раньше думал, что придётся переходить на postgresql, ибо в мускуле всё плохо с репликацией, failover и вообще версия 5.5 (которая появилась после покупки ораклом) у них очень плохая вышла. Коммуна была расстроена и считала, что оракл убьёт мускуль. Но в феврале этого года вышла версия 5.6, которая удивительно хорошо работает - быстрее 5.5, добавлены фичи для репликации из коробки, для php выпустили плагин с load-balancing и failover. В общем, похоже мускуль воскрес из мёртвых и мне это нравится, ибо не хочется переучиваться на постгрю.
3) написал хостеру, что наблюдаю днём пакетлост 0.1%, а по вечерам наблюдаю пакет-лост 0.5%. На удивление, не послали нахрен, а начали разбираться. Хоть и достаточно вяло.
4) после того, как перешёл на swift, на серверах стало нехватать памяти (всего 16Гб). Пришлось перейти с apache на nginx+php-fpm. Из-за того, что фротэнд держал с бэкэндами keel-alive соединения, получил выигрыш в памяти в 3 раза - 300 Мб вместо 1Гб.
5) настроил себе в заббиксе красивые картинки. Теперь если что-то торимозит - я не бегаю по серверам, а запускаю один экран и всё сразу видно:
- Сколько будет стоить аренда канала 1Гбит для выделенного сервера (без учёта стоимость аренды сервера)?
- Месячная аренда канала в 1 Гбит/с для выделенного сервера составляет 90000 рублей.
- Судя по новости http://selectel.ru/news/increasing-network-connection-speed-to-100mbits/ - если я закажу 9 самых дешёвых серверов и не буду использовать их, то получу 1Гбит за 13500 руб. Так?
- Если на Вашем аккаунте есть 10 заказанных серверов, то Вы можете запросить смену учета трафика. После чего да, Вы сможете использовать 1 Гбит/c на все 10 серверов или 1 в отдельности.
- Месячная аренда канала в 1 Гбит/с для выделенного сервера составляет 90000 рублей.
- Судя по новости http://selectel.ru/news/increasing-network-connection-speed-to-100mbits/ - если я закажу 9 самых дешёвых серверов и не буду использовать их, то получу 1Гбит за 13500 руб. Так?
- Если на Вашем аккаунте есть 10 заказанных серверов, то Вы можете запросить смену учета трафика. После чего да, Вы сможете использовать 1 Гбит/c на все 10 серверов или 1 в отдельности.
Что-то в последнее время у меня слишком много админских событий, что не очень радует... не люблю я нервничать.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 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. И он отвечает - что есть куча проблем, но если бы платные были, то наверное этих проблем бы небыло. Так вот - эти проблемы у них независимо от того, сколько им платишь =)
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме (+23 постов - )
Наши любимые теги
Hoshimi Miyabi
Zenless Zone Zero
Tea Patriarch
Anime Artist
EGS халява
Epic Games Store
floradaria
nsfw
mikimakey
nsfw
DifmanM
nsfwartist
AromaSensei
nsfwartist
Топ комментов
А бывает, комменты лучше постов. Смотрим топ тредов и вникаем!