2 posts tagged

Linux

DigitalOcean так и остается хостингом для пет-проектов

Digital Ocean – это такой облачный хостинг, который любят за недорогие цены на небольшие виртуалки для дев целей и прикольные мануалы. Они очень пытаются быть модными и крутыми, делая всякие маркетплейсы с готовыми сборками разных утилит, предлагая функциональные кластера Кубера, вводя в линейку memory-optimized сервера, позволяя создавать отдельные приватные сети для конкретных машин, создвать теги и называя свои сервера Дроплетами. Под словом пытаются я хочу сказать, что сами они себя ставят в один ряд с AWS и GCM. Но нельзя просто так взять и стать топовым облачным провайдером. На собственном примере расскажу, почему меня в этом не убедили.

О чем это я

Я не буду томить долгими рассказами и сразу озвучу главную мысль. Самое главное в сервисах, которые пытаются быть гибкими и оказывать качественные услуги сложнее интернет-магазина с самовывозом – это саппорт и фидбек о текущем состоянии услуг. Это особенно актуально для виртуализированных ресурсов, где клиент не имеет возможности вообще понять, что на самом деле происходит с его серверами. Для меня облачные сервера всегда значили, что они слабее выделенного сервера в реальном ДЦ и с этим не было проблем, это логично. Но смысл облачных серверов в том, чтобы проблемы с железом решались на том же уровне – там где я вообще не вижу, что происходит. К чему это я.

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

1 и 2 случаи

БД начинает много писать и читать. Быстро упростить нагрузку и не накосячить не получится, нужно немного пожить в этом состоянии – иопсы под потолок, цпу скачет туда-сюда каждый вечер, слегка рисуя iowait. Сервер ресайзить нет смысла, вся нагрузка упирается в диск. Хотелось бы отключить логи и снизить нагрузку на диск, но логи были нужны. Решение было очевидное – подключить еще один диск, писать логи в него. Так и сделали – хорошо живем, вроде чуть попроще стало. Как-то раз девелопер решает зафигачить большой-большой запрос по логам, который он делал и раньше. Бамс основной диск ложится. “Но ведь это два разных диска!” – говорили они мне. Оказывается, не особо. Я сейчас уже этот момент на графиках в истории на найду, но там было видно, как подскочили показатели сразу двух дисков одновременно и вернулись, как только запрос отменили. Ну, штош, решили пока не делать таких запросов.
Прошло пару дней и внезапно диски упали вообще. CPU показал 99% iowait, записи и чтения нет, сервер сам доступен. Опытным путем выяснили, что проблема с диском логов – база не может записать лог и валится. Сервер уходит в ребут – нет эффекта, через пару минут тоже самое. Выключили сервер через дашборд DO и включили. Ожило, но ненадолго. Чтобы понимать, выключаются “жирные” сервера всегда долго, поэтому до факта самого отключения может пройти и минут 6-7, а потом еще пару минут до запуска, то еще удовольствие. Решили отсоединить диск полностью и выключить логи, чтобы хоть что-то работало. Снова ребут – все работает. Ну, ок, больше не экспирементируем с разделением дисков, уговорили.
Что примечательно, когда я почти сразу расписал эту ситуацию саппорту, объяснив, что как-то не очень хорошо, когда мы теряем критические компоненты сервиса с неуловимыми косяками. Мне ответили на следующий день, часов через 16. Ответ классный:

We are sorry to hear you are seeing issues accessing that volume. In this case can you try detaching that volume, powering the droplet off, attaching it again then powering it back on. Please then run a file system check on that volume to be sure that there are not file system errors there causing issues.

Спасибо. Дальше я что-то писать не стал, понятно, что всем пофигу.
Второй раз повторилось примерно тоже самое. Давайте вспомним, что у нас уже один диск как и было раньше, все должно быть хорошо. Но через еще четыре дня снова прилег диск, но только теперь сразу был 99% iowait, а никакие ребуты не помогали. Получается, мы убили этот сервер) В этот раз мы просто переключились на реплику, она стала новым мастером. Старый Дроплет очнулся только через час! Удалили и забыли.
Выводы: что два диска, что один диск, обе этой херни сами понимаете что. Я писал в сапорт, чтобы они хоть как-то разобрались или сказали бы, что что-то пошло не так. Но мы до сих пор не знаем, ни что пошло не так, ни что толком делать, если повторится, кроме как менять дроплет.

3 случай

Это не то чтобы косяк и, наверное, надо было сразу читать документацию, но нормальные поцоны же не в курсе, что это. У DO есть так называемые Spaces – файловые хранилища по типу S3 бакетов Амазона. Собственно, это полный аналог с таким же апи, но одним небольшим отличием. У этих бакетов есть https://www.digitalocean.com/docs/spaces/ лимиты. Лимиты на операции записи, удаление и даже на объем загружаемого за день:

Spaces have the following request rate limits:
750 requests (any operation) per IP address per second to all Spaces on an account
150 PUTs, 150 DELETEs, 150 LISTs, and 240 other requests per second to any individual Space
2 COPYs per 5 minutes on any individual object in a Space

И бла-бла-бла. Я могу ошибаться, но на Амазоне такого нет. Это как по мне полный идиотизм и вот почему. В моем понимании все эти бакеты созданы для того, чтобы клиент не морочился с поддержкой своего хранилища. Оно просто существует где-то, что-то делает. Заливай, отдавай. Я думаю можно прекрасно предположить, что в более-меннее крупном сервисе 150 путов в секунду это вообще не много. Наверное, действительно крупный сервис уже задумался о распределении таких нагрузок, хотя казалось бы зачем, если платишь за готовое решение. Но ирония в том, что это действительно очень мало.
Традиционно, мы хранили там статику. Весь контент, который аплоудили юзеры, уходил туда. И вот мы решили залить множество небольших файлов, обновить много контента и нахреначили скрипт, который заливал кучу мелких картинок в этот бакет. В какой-то момент эти операции просто начали упираться в лимиты, что скрипт, конечно, игнорировал, ибо о такой штуке никто даже не подумал. Я увидел проблему, когда пару юзеров не смогли загрузить себе аватарочку:

An error occurred (SlowDown) when calling the PutObject operation (reached max retries: 4): Please reduce your request rate.

После этого скрипт остановили, ограничили его скорость, и все стало хорошо. Это все же глупость. Раз и есть лимиты, могли бы хотя бы о них предупреждать при создании бакетов, это же важный аспект. Так же я бы не отказался от платного расширения этих лимитов. Бакет сам по себе достаточно не дорогой, поэтому это можно было бы оправдать, если бы была возможность исправить это. Я ведь не удивлюсь, если лимит существует не на бакет, а на аккаунт, и создание нескольких не поможет.

4 случай

И снова проблема бакета. Я просто оставлю это здесь:

Просто взять и просрать сертификат к сервису на ровном месте. По истории инцидента видно, что проблема исправилась через час, но на деле сам инцидент был создан минут через 30 после того как у всех отвалились картинки. Опытным путем выяснили, что проблема была только на CDN адресе, а по обычному работало, и мы быстро переключились. Поэтому не сильно пострадали, но, как можно понять, вся статика у юзеров просто перестала отображаться, потому что клиенты не будут ничего загружать без SSL.

Что имеем

Имеем, что я однозначно буду советовать всем уезжать с DO, когда есть понимание, что проект сталкивается с большими нагрузками. Что будет происходить, если бы мы увеличились в наших RPS раза в три, я даже боюсь представить. Я уже молчу про аномальные сетевые ошибки, которые происходят периодами раз в пару дней, которые вообще никак толком не отловить.
DO идеален, чтобы поднять себе какой простенький впн (скачка торентиносов там, кстати, очень жестко палится, сразу приходят авто-страйки от правообладателей), хостить там свой сайт, на который никто кроме вашей мамы не заходит, или играться с новыми технологиями. У них много классных штук, тот же интерфейс дашбода вряд ли у кого-то найдется лучше, но внешний вид и исполнение все же принципиально разные вещи, а особенно в данном случае.
Я могу ошибаться, может это были частные случаи, но мой опыт таков. Пока писал этот текст, нашел, что существует Premier Support. Попробую узнать прайс и попробовать, может мой мир станет лучше.

 No comments    224   5 mon   Develop   Digital Ocean   Linux   Servers

Свой DNS сервис с блекджеком и блокировщиком рекламы

Мы любим Адблоки и не любим рекламу. Но, например, на телевизоре нет Адблока, да и плагина для апки YouTube в SmartTV вряд ли найдется. Да и вообще, зачем этот телевизор ходит по трем разным адресам Самсунга по кд, даже когда им не пользуются? В этот раз про очередные попытки обмануть систему и хакнуть время.

В заметке про борьбу с отвлечениями в работе я приводил в пример пару Адблоков, а так же упомянул, что существует возможность всю эту хрень блокировать на уровне DNS для самых упоротых. Тулза называется Pi-Hole. Это опенсорсная разработка, которая подразумевает установку на Raspberry Pi и подключение напрямую к домашнему роутеру. Но, конечно, ее можно поставить где угодно, так как это обычный пакет для Линукса.

Как это работает?

Нужно просто вручную вписать адрес Pi-Hole в DNS на роутере (или на компе) и трафик пойдет через него. Он в свою очередь все отфильтрует, запишет и пустит в эти ваши интернеты. Заблокирует всю рекламу, сервисы сбора аналитики, трекинговые ссылки – в общем, все что не требуется непосредственно для работы приложений.
По адресу Pi-Hole доступен дашборд, на котором можно полазить и посмотреть весь трафик:

А вот так, например, выглядит лог запросов:

На скрине видно, что блокируется сбор аналитики.

Собственно все. Профит.
Можно создавать свои блек/вайт листы, анализировать топ клиентов и доменов и прочие ништяки. Но уверенно заявляю, что из коробки он свою задачу отлично выполняет, можно не париться.

Как установить

Пару команд. Инструкции на официальном сайте.
Есть мануал и для докера.
Для ленивых – готовая сборка в связке с OpenVPN на маркетплейсе Digital Ocean. Но в ней подвох – сертификаты живут 3 месяца, якобы ради безопасности. А потом нужно создать новый сервер, лол. Странное решение, но сервер действительно ставится в один клик и сразу выплевывает VPN сертификат. В роутер, наверное, этот DNS сервер уже не пропишешь, ибо изначально он доступен только внутри туннеля. Не забудьте включить на Дроплете IPV6 адрес, чтоб не быть лохом.
К слову, работа Пайхола и ВПН сервера будет самым разумным решением, лучше так сразу и делать.

Тормозит?

Задам встречный вопрос – а вы вообще в жизни ощущаете, как работает обычный DNS? Вот тут тоже самое. Я допускаю минимальные задержки, если Pi-Hole захостится где-нибудь в Европе на удаленном сервере (хотя сам не замечаю такого), но если ставить дома, то точно ничего не изменится, а скорее всего станет даже быстрее.

Что еще сделать

Вкатить DOH. В оф доке Пайхола есть страничка о том как настроить DNS over HTTPS через Cloudlfare. Можно стать очень модным.
Конечно, Расбери покупать не обязательно. Можно купить робот пылесос Xiaomi и установить Пайхол на него. Он все равно весь день стоит включенный и сидит в сети. Не шучу – именно так изначально и делал сам. Конечно, был геморрой доустановки пакетов (в дефолтной ОС робота не установлен даже wget), потом естественно закончилось место и последовало несколько сбросов прошивки, получения рут прав и т.п., но в конечном итоге он завелся и работал. Но этот вариант не прижился, так как я не хотел ограничивать использование DNS сервера домом, а пробрасывать робота в мир не хотелось. Так что как будет работать в долгосрочной перспективе – не знаю.

Минусы

  • К этому DNS серверу может подключиться кто угодно – через пару дней использования вы заметите приходящие сканеры в клиентах Пайхола. Не то чтобы это проблема, но как-то неприятно.
  • Админка хоть и запаролена, но по дефолту открыта в вебе. Если сидеть под впном и разместить Пайхол на том же сервере, то по ip/admin любой узнает, что стоит DNS сервер. Как вариант решения – закрыть страницу за авторизацией веб сервера или может за порт хотя бы не стандартный воткнуть.

Итого

  1. OpenVPN
  2. PiHole
  3. Cloudflared
  4. Выебываемся перед корешами.

Референсы

Pi-Hole
Digital Ocean Marketplace
Configuring DNS-Over-HTTPS on Pi-hole – Pi-hole documentation
NetworkConfiguration – Debian WikiLocal DNS Resolver on Ubuntu

 No comments    164   9 mon   Linux   PiHole   Productivity   Security