Рейтинг
0.00

TimeWeb Хостинг

1 читатель, 31 топик

Облачные серверы в Москве



Открыли возможность создавать облачные серверы в Москве. И вместе с этим опцию создавать их без IP-адреса.

Москва — наш третий инфраструктурный регион в России.

Мы тщательно подбирали площадку и остановились на IXcellerate Moscow South. Это современный Tier III со всеми передовыми технологиями резервирования и защиты данных.

Первое отличие новой локации — гигабитный канал. Это в 5 раз больше Питера, и в 10 больше Новосиба. На канал даем 64 терабайта трафика в месяц бесплатно. Этого с головой хватит на большинство задач и в то же время не даст забить канал чем-то ненужным. Превышение платное — 200 руб/Тб.

Второе — возможность создавать серверы без внешнего IP, исключая их стоимость из цены. Например, если вам нужен сервер в приватной сети (скоро добавим) без внешнего IP, стоимость начинается всего от 150 рублей.

Минимальная конфигурация стандартная: 1 CPU, 1 Гб RAM и 15 Гб NVMe. Обойдется в 300 рублей в месяц вместе с IP. Максимальная — 8 CPU, 16 Гб RAM, 160 Гб NVMe — в 4 200 рублей.

Произвольные тоже на подходе, скоро добавим.
timeweb.cloud/my/servers/create?location=ru-3&zone=msk-1&preset=4795&os=79

«Поздравляем с терабитом». Та самая статья про DDoS-2023 — без цензуры





Дисклеймер ↓
Этот материал должен был выйти в декабре 2023, прямо перед Новым годом, — и это классический пример про «лучшее враг хорошего». Сначала нам не нравилось, что мало подробностей. Потом — что их излишне много. Была версия с цитатами, но без скринов. Со скринами, но без цитат. Мы записали столько интервью с сетевиками, что сами в них запутались.

Но в итоге сегодня наша статья наконец-то выходит в свет. Из цензуры — только внимательная рука корректора. Передаем слово Максу Яковлеву.

Меня зовут Максим, я руковожу отделом сетевых инженеров в Таймвебе. Как вы уже поняли из заголовка, речь пойдет про наш прошлогодний DDoS. Это не стандартный постмортем, а скорее история от первого лица. Расскажу и покажу, каково это было изнутри — жить на энергетиках и пересобрать ядро сети всего за пару месяцев.



❯ Некоторое время до
Про Таймвеб вы, скорее всего, знаете. И скорее всего — как про хостинг, работающий по модели shared, с саб-сервисами вроде регистрации доменов, конструктора сайтов и пр. Еще есть облако, выросшее из хостинга, — о нем и пойдет речь.

В 2023 мы начали потихонечку распиливать легаси-сеть хостинга и делать ее похожей на сеть IaaS-провайдера. Но в целом архитектура на момент дня Х была довольно типичной для хостинга: несколько маршрутизаторов, стопка растянутых VLAN, три транзита и пара обменников.

В хостинговом бизнесе объем каналов рассчитывается от объема общего трафика на сеть, плюс запас на случай аварий и атак, обычно не превышающий 10х от трафика в ЧНН. Отсюда выстраивается защита инфраструктуры и клиентов: оценивается максимально ожидаемая совокупная мощность атак, берется небольшой запас и подбираются механизмы противодействия, чтобы и отдельного клиента защитить, и самим при этом не упасть.

Важно понимать, что любой типичный хостинг находится под DDoS-атакой практически 24/7: хоть одного клиента в каждый момент времени да атакуют. Поэтому DDoS для нас — это даже несколько банально. За 17 лет мы повидали много чего и в принципе знаем ключевые (и не только) паттерны, откуда, что, куда и как.

❯ Добрый вечер
14 сентября, ближе к 18:00, в нас влетел очередной DDoS, с которым известно что делать. Отбили — пошли отдыхать. И не успел я допить чай, как атака повторилась, потом опять, а потом еще раз. Каждый раз интервал уменьшался, а объем нарастал.

Скриншот от StormWall в тот момент

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

В площадку наливается больше, чем та способна переварить → роутеры перегружаются вплоть до потери сигнализации → мы через OOB блокируем атаку через RTBH/FS или переключаем сеть на сторонний центр очистки трафика → цель атаки меняется в течение пяти минут.

Из дополнительных проблем в СПб: аплинки подключены через свитчи с переподпиской, QOS или не работает, или не хватает буфера → разваливается сигнализация. Дополнительно существуют громадные растянутые VLAN, из-за чего атака на одну подсеть затрагивает огромное количество клиентов. Мониторинг и контрмеры работают слишком медленно.

Иногда приходилось расставлять приоритеты

И в остальных локациях: нет своей сети, а ЦОДы нас блочат, защищая свою инфраструктуру. Когда сеть отдается напрямую с железок дата-центра, нет не то что возможности заблокировать атаку, затруднена даже идентификация паттерна: раз — и ноды отвалились. Из доступной информации только триггер в Заббиксе. Самые печальные моменты — когда у нас сутками лежало несколько локаций целиком и наглухо. Даже аплинки наших провайдеров в дата-центрах просто говорили, что мы не готовы это фильтровать, поэтому мы вас отключаем. Как атаки прекратятся, подключим обратно.

❯ Мы накидываем план
Первое: научиться блокировать хотя бы часть атаки на уровне маршрутизаторов провайдеров. Цель — снизить воздействие на клиентов, защитить инфраструктуру. Второе: научить нашу сеть переваривать всю аплинковую емкость без спецэффектов, параллельно ее расширяя.

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

И стратегически: построить свои сети во всех локациях. И собственную защиту.

В первую очередь отказываемся от существующей системы подавления DDoS, потому что она приносит больше вреда, чем пользы. Сетевики начинают спать по очереди, текущий flow-мониторинг меняем на семплированный Inline IPFIX с payload-ом. Таким образом не ждем, пока соберется поток, и принимаем решения за секунды. Этот шаг помог уменьшить среднее время обнаружения каждой атаки: чтобы понять, что она началась и как нужно действовать, нам сначала нужна была пара минут, чуть позже — 15 секунд, а сейчас автоматика реагирует почти мгновенно.

Рабочая обстановка

Изначально управление было ручным, чуть позже принятие решений стало автоматизированным: мониторинг научился блокировать DDoS сразу же после обнаружения. В итоге за период с 14 по 20 сентября мы заблокировали более 20 тысяч отдельных паттернов.

В это время по всем каналам — в телеге, в соцсетях, в тикетах — клиенты переживали, ругались и задавали вопросы. И я их прекрасно понимаю. Кстати, о прекрасном:


Дорабатываем защиту: делаем ее быстрее, технологичнее, чтобы принимала максимально правильные решения. Разбираем всю старую архитектуру и избыточные куски сети — все под нагрузкой и идущими атаками и так, чтобы воздействие на клиентов было минимальным.
Примерно в это же время атакующие понимают, что мы что-то сделали, поэтому меняют паттерны. Мы стали получать мощные краткосрочные волны трафика, на которые не успевала реагировать ни наша программа, ни большинство предлагаемых на рынке защит: заливало настолько разнообразно и быстро, что наши стыки и некоторые обменники начали складывать в нас сессии по prefix-limit. В эти периоды бывало и такое:


❯ Строим свою сеть
Начинаем с Питера. План включал в себя апгрейд маршрутизатора с установкой дополнительных плат и подключение к различным каналам и точкам обмена трафиком. Цель — увеличить пропускную способность: нам нужно было научиться принимать трафик атак и блокировать более точечно, а не просто кидаться блекхолами и снимать префиксы. Кроме того, стало понятно, что объемы атак могут расти и нам нужно будет научиться расширять емкость более оперативно, не проходя весь цикл «найти железо → найти емкость → собрать».

Главный роутер в СПб. На скрине MX480 в составе 2xSCBE2, 2xRE-S-2X00x6, 4xMPC7E MRATE

Обычные маршрутизаторы не всегда эффективны для такой деятельности: они обладают слишком сложным и дорогим конвейером обработки трафика, предназначенным для других задач. Исходя из этого мы решили действовать комплексно: помимо расширения каналов и увеличения портовой емкости сервисных и пограничных маршрутизаторов начали внедрять пакетные платформы на базе Juniper PTX. Они хоть и попроще, но в них много дешевых 100G/400G-портов, как раз то, что нам нужно.

Благодаря хорошим отношениям с поставщиками мы смогли быстро найти сетевое оборудование: поставка заняла всего полтора месяца. Для техники такого класса это очень быстро.

В итоге в Питере мы добили емкость по основным направлениям до 500+ гбит, а по автономке у нас сейчас суммарно около терабита. Уже через две недели после этого ситуация в СПб стабилизировалась: емкости хватало, фильтры отрабатывали оперативно. В остальных локациях сеть была арендованная: и в Казахстане, и в Европе. По этой причине параллельно с выравниванием ситуации в Питере у нас появилась новая приоритетная задача: поставить в заграничные локации собственные маршрутизаторы и дотянуться до них из Питера — тянуться решили через M9.

Девятка до сих пор крупнейшая пиринговая точка и сосредоточение телеком-инфраструктуры РФ и СНГ. Кроме основных трасс для всей России, туда же заходят каналы от СНГ — зачастую единственные.

Магистральные каналы между площадками дают несколько преимуществ:
  • Возможность отправлять и получать трафик через любые другие стыки Таймвеба во всех странах.
  • Возможность предоставлять клиентам дополнительные сервисы в виде каналов связи.
  • Наше управление не развалится никогда, даже если внешние стыки в локации будут забиты под полку.

Собственно, начинаем с Казахстана. Протянули канал до девятки и пустили трафик уже через свою сеть.


MX204 на девятке, собирает магистрали и внешние линки. Скоро заменим его 960-м и будем забивать сотками

Кстати, с доставкой в Казахстан повезло не с первого раза. На казахской таможне менялся состав — и все встало мертвым грузом. Ситуацию решили творчески: отправили одного из наших сотрудников везти 204. Забавно, что изначально мы собирались отправлять MX104 — довольно старую и давно снятую с поддержки платформу, которой, впрочем, с запасом хватает на нужды этой площадки.

MX104 со склада — кусочек истории телекоммуникаций

Но из-за ее громоздкости отправили 204 — и теперь в казахстанском ЦОДе у нас стоит платформа, которой хватит на целый машинный зал облака, а не на наши несколько стоек. На память осталась только фотка со стикером из аэропорта Екб:


К декабрю дотянулись и в Европу: теперь у нас есть узлы во Франкфурте и Амстердаме с арендованной магистральной емкостью. Там появились выходы и в интернет — через Tier-1 операторов, и на европейские обменники.

Следующий логичный шаг — перевели площадки в Амстердаме и Польше на свою сеть. Теперь нас никто не отключит в случае атак, как бонус — интернета стало больше и появились выделенные каналы для клиентских выделенных серверов, скоро будут и во всем Клауде. В итоге вы сможете не только заказать себе сервер с 10G-интернетом, но и расширить локальную сеть до любой нашей точки присутствия — с гарантированной полосой и любыми удобными вам настройками.

Раз уж пошли по локациям, то добавлю, что в этом году запустились и в Москве, в IXcellerate. Это Tier-3 с уникальной системой охлаждения по типу «холодная стена». Я там был на экскурсии — наверное, самое интересное, что я видел в России и СНГ, а поездил я немало. Пиво еще вкусное у них было — тоже плюс.

Москва, кстати, у нас сразу же запустилась с нормальной архитектурой: широкие линки на стойку, 200G до девятки, масштабируемый слой агрегации. По умолчанию даем на все виртуальные серверы по гигабиту в секунду вместо 200 мегабит, на всех дедиках доступно 10G/40G по запросу. В результате, если клиентам это необходимо, мы можем дать гораздо больше емкости, чем могли бы в Петербурге еще полгода назад.

2xQFX5120-32C в IXcellerate

❯ Почему мы не спрятались за подрядчиками
На самом деле мы обращались к нескольким компаниям, но на тот момент уже стало понятно, что у нас не получится использовать их как общее средство защиты для всей сети.

Решения по комплексной защите от DDoS, по сути, делятся на два вида: это готовые решения, устанавливающиеся непосредственно на сети компании, и сторонние центры очистки трафика, через которые этот самый трафик нужно пропускать. На тот момент у нас существовали собственные чистилки и был опыт постройки подобных решений. Посоветовавшись с коллегами по цеху, решили двигаться именно по такому сценарию: принимать трафик → очищать большие потоки на уровне сети, привлекая центры очистки в отдельных случаях → заниматься тонкой очисткой с помощью вендорских решений.

Важно отметить, что при использовании внутренних решений для защиты от DDoS необходима сеть, способная обрабатывать и фильтровать трафик, не затрагивая других клиентов или локации. То, что отфильтровать не удалось, должно быть направлено на системы тонкой очистки с минимальной задержкой и воздействием на чистый трафик.

Необходимо было сначала усовершенствовать сеть до этого состояния, а затем заниматься внедрением коробочных решений. Мы переводили атакуемые подсети в партнерские центры очистки, хоть иногда это больше аффектило на нормальный трафик, чем помогало.

Такое положение дел было связано с характером самого трафика и с тем, что атаки были короткими и частыми: классифицировать «чистый» трафик в подсети, состав серверов которой меняется от недели к неделе, если не чаще, — малореально. А переключить маршрутизацию за время между атаками часто и вовсе не получается: цели меняются быстрее, чем BGP-апдейты распространяются по интернету.

❯ Что сейчас
Подобные атаки прилетают, но в целом мы научились их фильтровать: чистить на уровне сетевого оборудования или деприоритизировать/блокировать клиента, если объем превышает пороги.

Работы еще много: всю эту новообразовавшуюся сеть нужно резервировать и расширять. На М9 мы взяли целую стойку и собираемся ставить шасси MX960 — с большим запасом на будущее. Оно будет выполнять роль магистральной развязки, принимать внешние стыки и выступать ядром сети дата-центров по Москве, у нас там большие планы. Не забываем и про Северную столицу: платформа PTX10003 станет ядром нового узла на Кантемировской («Радуга»), где будет перемыкать магистрали и стыки с внешними сетями, выступая частью инфраструктуры очистки трафика в Санкт-Петербурге.

Находимся на этапе тестирования с Servicepipe: будем пробовать систему уже тонкой очистки трафика — если атака на клиента не угрожает инфраструктуре, не полностью все блокировать, а принимать трафик атак на себя и отдавать клиенту уже очищенный, вплоть до L7.

Много работы будет по пирингам: думаем, что скоро мы сделаем прямые подключения к Google, AWS, Azure и другим гиперскейлерам. Хотим организовывать серьезные продуктовые преимущества для наших клиентов: если ваш продукт требует очень хорошей связности с мировыми облаками или у вас мультиклауд — мы сможем обеспечить как хорошую связность по интернету, так и выделенные линии, если потребуется.

Для выделенных серверов по части сети у нас получилось очень интересное предложение. По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет. Кроме простого интернета — широкий набор сетевых решений: тут и более-менее стандартные L2/L3 VPN на MPLS, и любые манипуляции с внешней маршрутизацией. Для владельцев своих AS соберем транзит, притянем любую популярную точку обмена трафиком. Для тех, кто хочет ими стать, — поможем выпустить ASN, арендовать или купить сети, анонсировать их в мир.

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

❯ И напоследок — неудобный вопрос от маркетинга
Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?
Расширение в целом планировалось, Таймвеб всегда делал упор на качество сети, но процесс шел постепенно. Исторически мы сфокусировались на нашем центральном хабе в СПб, а стройка в остальных локациях планировалась по мере их расширения.

А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.

С каждым шагом сеть крепчает, а атаки становятся менее заметными



Сделано много работы, коротко:
  • Поставили и перенесли сервисы на новый мощный роутер (последние тех работы об этом)
  • в Спб расширены входящие каналы, съели практически всю емкость, которую можно забрать с Цветочки, на неделе еще подключим пару сотен гбит емкости, а остальное заберем с Москвы. Запущены фильтры, которые чистят атаку.
  • в Мск развернули точку присутствия, роутер, свои каналы, будем принимать там большой трафик и чистить, включаем фильтрацию в течение недели, отдаем чистый трафик в СПб и Казахастан
  • в Казахстане поставили новый роутер, проложили канал Мск-Алматы (5000 км), не зависим от местных аплинков, которые не выдерживают атаку и снимают анонсы.
  • в Европе запустили две точки присутствия в Нидерландах и Франкфурте со своими каналами и роутерами, тянем каналы до локаций в Нидерландах и Польше, настраиваем фильтрацию как в Спб и Мск.

С каждым шагом сеть крепчает, а атаки становятся менее заметными. Что-то прилетает и влияет на сеть, задача свести влияние к минимуму. Сильно проинвестировали в развитие сети, скоро будем по сетевой мощности как телеком оператор. Спасибо ддосерам, за счет такого буста по сети мы сможем в дальнейшем давать сервисы локальной сети между ДЦ и защищенные каналы и другие сетевые плюшки между всеми локациями.

timeweb.cloud

Новый роутер Juniper MX480 в инфраструктуре Timeweb Cloud



Усилили основной хаб нашего облака новым отказоустойчивым роутером Juniper MX480. С виду это простая коробочка, а на деле — универсальная платформа маршрутизации.

Чем он так хорош?
  • Полностью дублирует компоненты управления и передачи данных. А это гарантия бесперебойной работы сети.
  • Поддерживает мультисервисную маршрутизацию трафика — 100 Гбит/с.
  • Две интерфейсные платы MPC7E-MRATE работают на высоких скоростях — 480 Гбит/с каждая. В будущем добавим еще четыре и ускоримся до 2,8 Тбит/с.
  • Поддерживает работу с миллионами маршрутов — отправляем ваш трафик по самому короткому пути.

Что еще умеет
  • Выполняет функции файрвола на уровнях L3/L4.
  • Защищает от DDoS-атак.
  • Работает с L3VPN/MPLS.
Одним словом — хорош. Делаем все, чтобы облако Timeweb Cloud было доступно и функционально на разных уровнях, в том числе на сетевом.

Изменение стоимости VDS



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

Мы удерживали цены на прежнем уровне в течение полутора месяцев, однако, чтобы продолжать оказывать качественный сервис и развивать продукты под ваши задачи, мы должны сделать этот шаг.



Как сохранить старую цену
Чтобы сохранить текущую стоимость услуг — продлите их до 11 апреля. Всем клиентам, которые успеют это сделать, мы оставим старые цены на период продления.

Также мы предусмотрели другие варианты, которые позволят оптимизировать ваш бюджет:

Снизили минимальный платеж до 50 рублей, чтобы оплачивать услуги по частям. Наш почасовой биллинг это позволяет.

Сохранили скидки при оплате на 3, 6 и 12 месяцев для всех, кто регистрировался до 11 марта 2022 года.

При возникновении вопросов обращайтесь к нам любым удобным для вас способом. И спасибо, что вы с нами.

timeweb.com/ru/

Итоги 2021 и большие планы на 2022!



Не ждите нового года,
чтобы превратить мечты в реальность
В прошлом году мы загадали желание — меняться и расти вместе с вами.

Оно сбылось — в этом году мы запустили много новых сервисов, обновили оборудование и заложили фундамент под масштабирование, улучшили качество поддержки.

Поэтому нам есть, что предложить взять с собой в 2022-й. Нужно только…
2022.timeweb.ru

Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS

Мы постарались кратко описать путь, который прошла команда Timeweb за 10 лет: от rsync, LVM и DRBD до ZFS. Эта статья будет полезна тем, кто занимается серверной масштабируемой инфраструктурой, планирует делать бэкапы и заботится о бесперебойной работе систем.


Расскажем о:
  • rsync (remote synchronization)
  • DRBD (Distributed Replicated Block Device)
  • инкрементальные бэкапы под DRBD с помощью LVM
  • DRBD + ThinLVM
  • ZFS (Zettabyte File System)

rsync и бэкапы до н. э.
rsync (remote synchronization) — вообще не про бэкапы, строго говоря. Это программа, которая позволяет синхронизировать файлы и каталоги в двух местах с минимизированием трафика. Синхронизация может выполняться и для локальных папок, и для удаленных серверов.

Достаточно часто rsync применяется для резервного копирования. Мы использовали эту утилиту, когда сайты были проще, а клиентов было значительно меньше.

Rsync неплохо справлялась с задачей, но самая большая проблема здесь — скорость. Программа очень медленная, она сильно нагружает систему. А с увеличением данных, начинает работать еще дольше.

Rsync можно применять в качестве технологии бэкапирования, но для совсем небольшого объема данных.

LVM (logical volume manager) — менеджер логических томов
Конечно, нам хотелось делать бэкапы быстрее с наименьшей нагрузкой, поэтому мы решили попробовать LVM. LVM позволяет делать снапшоты, даже используя ext 4. Таким образом, мы могли делать бэкапы при помощи снапшота LVM.

Эта технология использовалась нами недолго. Хоть бэкап и выполнялся быстрее, чем в rsync, но он был всегда полный. А хотелось копировать только изменения, поэтому мы перешли к DRBD.

DRBD
DRBD позволяет синхронизировать данные с одного сервера на другой. При чем синхронизируются только изменения, а не все данные. Это значительно ускоряет процесс!

А на стороне стораджа мы могли использовать LVM и делать снапшоты. Такая система существовала очень долго и существует сейчас на части серверов, которые мы еще не успели перевести на новую систему.



Однако и при таком методе все равно существует недостаток. При синхронизации DRBD сильно нагружает дисковую подсистему. Это значит, что сервер будет работать медленнее. В результате бэкап мешал работе основных сервисов, то есть сайтов пользователей. Мы даже старались делать бэкапы в ночное время, но они иногда просто не успевали завершиться за ночь. Приходилось маневрировать, чередовать бэкапы. Например, сегодня выполняется одна часть серверов, потом другая. Разносили бэкапы в шахматном порядке.

DRBD, к тому же, сильно зависит от скорости сети и влияет на производительность сервера, с которого и на который ведется бэкап. Необходимо искать новое решение!

Thin LVM
В этот момент бизнес поставил задачу сделать 30-дневные бэкапы, и мы решили переходить на thinLVM. Основную проблему это так и не решило! Мы даже не ожидали, что потребуется настолько высокая производительность файловой системы для поддержания тонких снапшотов. Этот опыт был совсем неудачный, и мы отказались в пользу обычных толстых LVM снапшотов.

ThinLVM, на самом деле, просто не были предназначены для наших задач. Изначально предназначались для небольших ноутбуков и фотоаппаратов, но не для хостинга.

Продолжаем поиски…

Было решено попробовать ZFS.

ZFS
ZFS — неплохая файловая система, которая имеет множество уже встроенных плюшек. Что при ext 4 достигается путем установки на LVM, подключения DRBD-устройства, то при ZFS это есть по умолчанию. Сама файловая система очень надежная. Отдельно стоит отметить функцию Copy-on-write, эта технология позволяет очень бережно обращаться с данными.

ZFS позволяет делать снапшоты, которые можно копировать на сторадж, а также автоматизировать резервное копирование. Не нужно ничего придумывать!

Переход на ZFS был очень осторожным. Сначала мы создали стенд, где просто тестировали несколько месяцев. В частности пытались воспроизвести неполадки с оборудованием, питанием, сетью, переполнением диска. Благодаря тщательному тестированию, смогли найти узкие места.

Больная тема ZFS — переполнение диска. Эту проблему мы смогли решить путем резервирования пустого пространства. Когда диск переполнен, будут предприняты меры по разгрузке сервера и очистке места.

После тестирования мы постепенно начали вводить новые сервера, переводить старые сервера на ZFS. Проблем с бэкапами больше нет! Можно делать 30- или 60-дневные бэкапы, хоть бэкапы каждый час. В любом случае сервер не будет испытывать избыточных нагрузок.

Собрали все данные в таблицах ниже для сравнения бэкапов при использовании различных технологий.






Что было дальше?
В планах обновить ZFS до 2 версии OpenZFS 2.0.0. в 2021 году. Мы готовим переход с использованием всех фишек, которые были анонсированы с выходом релиза в начале декабря.

The Way this is!
Таков путь мы выбрали для себя! Решаете ли вы похожие проблемы? Будем рады, если поделитесь в комментариях опытом! Надеемся, статья оказалась полезна и, если вдруг перед вами так же стоит задача делать бэкапы с помощью встроенных утилит в Linux, наша история поможет подобрать подходящее решение.

timeweb.com/ru/

Причины пятничного сбоя



11.12.20 в 16:02 МСК мы столкнулись с аппаратной проблемой в работе системы маршрутизации. Серверы продолжали работать, но прекратили быть доступны извне. Сегодня мы расскажем, что произошло, что мы уже сделали и что еще предстоит сделать.

Что случилось
Проблема возникла на корневом маршрутизаторе, через который идет весь трафик. Он имеет собственное резервирование большинства функций на случай поломки. А то, что невозможно продублировать — зарезервировано вторым маршрутизатором, подключенным и готовым к работе.

Это значит, что если какой-то элемент корневого маршрутизатора выходит из строя, второй роутер незамедлительно подключится к работе. И, в целом, такая внештатная ситуация не раз проигрывалась на тестовых испытаниях. Но не всё так просто.

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

Что происходило дальше
В период сбоя телефония была недоступна. Ребята из поддержек, из офиса и дома, не имея доступов к тикетам и телефону, переключились на сообщества в VK и Telegram.

В этот момент инженеры находились в поиске временного решения, которое позволит вернуться сервису в строй. К 18:55 МСК мы восстановили доступность сети.

На этом работы не закончились: уже ночью вместе с поставщиком оборудования мы доставили, установили и запустили абсолютно новый маршрутизатор, чтобы исключить любые просадки.

Сейчас работаем в штатном режиме: ловим и фильтруем атаки типа DDoS в адрес клиентских сайтов, следим и балансируем нагрузку на серверах. Помогаем в тикетах, по телефону, отвечаем в мессенджерах и соцсетях.

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

В настоящий момент мы находимся на связи с поставщиками оборудования: проводим аудит, проверяем совместимость версий ПО, выясняем наличие возможных незадокументированных проблем и уязвимостей в оборудовании, чтобы обеспечить заявленную стабильность.

Продолжаем поддерживать двойной резерв ядра сети и проводим дополнительные тесты бесшовного перехода между вариантами в случае возникновения любых нештатных ситуаций. Важно: такие тесты не затронут текущую работу сайтов клиентов.

Мы обеспечены всем необходимым запасом оборудования, вплоть до резерва кабелей. Более того, точка маршрутизатора стала нашим самым зарезервированным и безопасным участком.

Мы приносим извинения каждому, кто испытал сложности с доступом или понес финансовые/репутационные потери из-за аварии. И благодарны вам за взвешенную позицию и слова поддержки, которые вы писали, пока мы в поте лица занимались решением проблемы. Спасибо вам за доверие.

timeweb.com/ru/

Изменение стоимости виртуального хостинга с 14 декабря

С 14 декабря 2020 года начнут действовать новые цены на тарифные планы виртуального хостинга.
Ваш текущий оплаченный период не изменится, новая цена применится только при продлении хостинга в будущем.



Вы можете сэкономить при оплате услуги до 14 декабря, пока изменения тарифов не вступили в силу. Если деньги придут позднее, напишите нам об этом, и мы оставим вам старую цену. Всё честно.
Стоимость двухгодовых тарифов не меняется.
Они по-прежнему выгоднее остальных, и вы получаете в подарок два домена :)

timeweb.com/ru/services/hosting/