Рейтинг
0.00

TimeWeb Хостинг

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

timeweb.com/ru/

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

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



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

timeweb.com/ru/services/hosting/

Апгрейд VDS: новое железо, новые серверы и HighCPU VDS

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

Обновленная линейка VDS: новые тарифы без повышения стоимости.

Под капотом:
  • Процессоры линейки Intel Gold: +25% к производительности ядра.
  • Свежие диски NVMe: +150% к скорости диска в сравнении с SSD.

Нужно больше? Держите HighCPU-серверы:
  • 5.0 ГГц на процессорах i9-9900k и 2288g. Вместе с NVMe-дисками они дают, пожалуй, максимальную производительность, которую можно получить на VDS сегодня.
  • Идеально подходят под Битрикс и игровые серверы.

Протестируйте и расскажите о своих впечатлениях: дарим 6 месяцев VDS за обзор.


timeweb.com

Публикуйся в Timeweb Community и стань известным!



Публикуйся в Timeweb Community и стань известным!

Наш клиент Эмиль принял участие в акции «Платим за знания» и написал статью об SSL-сертификатах, которую за неделю прочитали 500 человек.

Безопасность, которую дарит https, сложно переоценить, но как выбрать SSL-сертификат? Статья Эмиля поможет вам в этом: в ней автор сравнил сертификаты от Let's Encrypt, Cloudflare и Free SSL Space и описал их преимущества и недостатки. Прочитать статью вы можете в нашем Community.

Вы тоже можете поделиться своими знаниями с другими пользователями! Станьте автором и заявите о себе на аудиторию в 150000 человек.
Условия нашей акции — на сайте.
timeweb.com/ru/services/bonuses/2852/

Впереди майские праздники — время отдыха, поездок и солнечных дней

Мы не будем блокировать аккаунты виртуального хостинга за неоплату с 1 по 5 мая. Оплатить сможете потом.

Хороших вам праздников! А мы проследим за стабильной работой ваших сайтов.

В новый год без забот: дарим месяц хостинга!


До 31.12.2018 всем новым клиентам на тарифах Виртуального Хостинга, Хостинга для 1С-Битрикс и Хостинга для CMS подарим дополнительный месяц на выбранном тарифе при оплате услуги за год по промокоду GODBEZZABOT.

Ввести промокод вы можете в разделе «Бонусы и промокоды» после оплаты хостинга.
timeweb.com/ru/services/hosting/

Timeweb вошёл в TOP-10 регистраторов доменов в зоне .RU

Немногие знают, что с начала 2018 года мы стали полноценно вести деятельность в качестве регистратора доменов в зонах .RU/.РФ.

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

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


Отдельно можно сказать, что толчком к решению стать регистратором послужило повышение цен на регистрацию доменов .RU/.РФ летом 2017 года.

Нам важно было сохранить цены для клиентов на регистрацию доменов на низком уровне без резких повышений. Можем сказать с уверенностью, что этого удалось добиться: стоимость регистрации .RU/.РФ всего 179 рублей.

При этом у нас получилось сохранить адекватную стоимость продления, сейчас она составляет всего 299 рублей/год.

Запуск самостоятельного регистратора
В конце 2017 года мы завершили многочисленные внутренние тесты и убедились, что в момент открытия регистрации доменов в зоне .RU/.РФ для клиентов не возникнет непредвиденных ситуаций и проблем.

В самом начале 2018 года, после окончания новогодних каникул мы переключили регистрацию новых доменов на систему регистратора Timeweb. С этого момента мы фактически начали свою деятельность в новой роли — регистратора доменных имен.

Кто мы сейчас
Спустя год мы вошли в топ-10 регистраторов страны по доменам .RU. При этом являемся одним из лидеров рынка хостинга.

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


Куда мы движемся
Наши планы амбициозны: в следующем году мы планируем войти в ТОП-5 регистраторов по зонам .RU/.РФ. Мы продолжим наращивать клиентскую базу, а также постараемся сохранить конкурентную стоимость регистрации и продления доменов.

Что получат наши текущие и будущие клиенты: быстрый и недорогой перенос домена к нам. Вы платите только комиссию, которая взимается за оформление процедуры Координационным центром национального домена сети Интернет — на текущий момент это всего 144 рубля.

Какие преимущества получили клиенты?
Являясь регистратором, мы можем держать цены для клиентов на невысоком уровне, поскольку теперь отсутствует «посредник» между нами и Реестром доменных имён.

Поэтому стоимость регистрации, продления и переноса доменов к нам — небольшая.

Стала ли проще процедура переноса домена с другого хостинга в Timeweb?
Конечно. Нужно всего лишь узнать код авторизации у своего текущего регистратора. Для этого потребуется поискать его самостоятельно в личном кабинете текущего хостинг-провайдера или регистратора, либо обратиться в их поддержку.

После того, как получите код — зайдите в раздел «Домены и поддомены», выберите «Перенос домена» и введите код.

После нажатия на кнопку «Перенести» и оплаты (сейчас перенос стоит 144 руб., но можно воспользоваться и бонусом, который добавляется на аккаунт виртуального хостинга при оплате за год) для домена будет заказан трансфер, о завершении которого мы проинформируем по e-mail.


Если вы хотите управлять доменами и хостингом из одной панели Timeweb, но сомневаетесь, как правильно это сделать — просто напишите или позвоните нам и мы ответим на все вопросы о процедуре переноса и подскажем, как действовать.

В случае, если вы готовы приобрести более 100 доменов, мы готовы предложить для вас специальную цену намного ниже рыночной (99 рублей) с адекватной ценой продления. Запросы отправляйте на почту: 2domains@timeweb.ru

Как мы выстрелили себе в ногу и пытались разобраться, из чего именно

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

Так выглядит тестовый сайт на каждом сервере виртуального хостинга

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

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

Лето прошло, и график uptime медленно ушёл вниз.


Администраторы сразу же определили причину – нехватка оперативной памяти. В логах легко было увидеть случаи OOM, когда на сервере кончалась память и ядро убивало nginx.

Руководитель отдела Андрей рукой мастера разбивает одну задачу на несколько и распараллеливает их на разных администраторов. Один идёт анализировать настройки Apache – возможно, настройки не оптимальные и при большой посещаемости Apache использует всю память? Другой анализирует потребление памяти mysqld – вдруг остались какие-либо устаревшие настройки с тех времён, когда виртуальный хостинг использовал ОС Gentoo? Третий смотрит на недавние изменения настроек nginx.

Один за другим администраторы возвращаются с результатами. Каждому удалось уменьшить потребление памяти в выделенной ему области. В случае nginx, например, был обнаружен включённый, но не используемый mod_security. OOM тем временем всё также часты.

Наконец, удаётся заметить, что потребление памяти ядром (в частности, SUnreclaim) страшно большое на некоторых серверах. Ни в выводе ps, ни в htop этот параметр не виден, поэтому мы не заметили его сразу! Пример сервера с адским SUnreclaim:
root@vh28.timeweb.ru:~# grep SU /proc/meminfo
SUnreclaim: 25842956 kB
24 гигабайта оперативной памяти отдано ядру, и ядро тратит их неизвестно на что!

Администратор (назовём его Гавриил) бросается в бой. Пересобирает ядро с опциями KMEMLEAK для поиска утечек.
Для включения KMEMLEAK достаточно указать опции, указанные ниже, и загрузить ядро с параметром kmemleak=on.
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=10000

KMEMLEAK пишет (в /sys/kernel/debug/kmemleak) такие строки:
unreferenced object 0xffff88013a028228 (size 8):
  comm "apache2", pid 23254, jiffies 4346187846 (age 1436.284s)
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace:
    [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50
    [<ffffffff811d450a>] kmem_cache_alloc_trace+0xca/0x1d0
    [<ffffffff8136dcc3>] apparmor_file_alloc_security+0x23/0x40
    [<ffffffff81332d63>] security_file_alloc+0x33/0x50
    [<ffffffff811f8013>] get_empty_filp+0x93/0x1c0
    [<ffffffff811f815b>] alloc_file+0x1b/0xa0
    [<ffffffff81728361>] sock_alloc_file+0x91/0x120
    [<ffffffff8172b52e>] SyS_socket+0x7e/0xc0
    [<ffffffff81003854>] do_syscall_64+0x54/0xc0
    [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a
    [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880d67030280 (size 624):
  comm "hrrb", pid 23713, jiffies 4346190262 (age 1426.620s)
  hex dump (first 32 bytes):
    01 00 00 00 03 00 ff ff 00 00 00 00 00 00 00 00  ................
    00 e7 1a 06 10 88 ff ff 00 81 76 6e 00 88 ff ff  ..........vn....
  backtrace:
    [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50
    [<ffffffff811d4337>] kmem_cache_alloc+0xc7/0x1d0
    [<ffffffff8172a25d>] sock_alloc_inode+0x1d/0xc0
    [<ffffffff8121082d>] alloc_inode+0x1d/0x90
    [<ffffffff81212b01>] new_inode_pseudo+0x11/0x60
    [<ffffffff8172952a>] sock_alloc+0x1a/0x80
    [<ffffffff81729aef>] __sock_create+0x7f/0x220
    [<ffffffff8172b502>] SyS_socket+0x52/0xc0
    [<ffffffff81003854>] do_syscall_64+0x54/0xc0
    [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a
    [<ffffffffffffffff>] 0xffffffffffffffff


Гавриил не раскрыл нам всех своих тайн и не рассказал, как он из вышеуказанных строк выяснил точную причину утечки памяти. Скорее всего, он использовал команду addr2line /usr/lib/debug/lib/modules/`uname -r`/vmlinux ffffffff81722361 для поиска точной строки. Или просто открыл файл net/socket.c и смотрел на него, пока файлу стало неуютно.

Проблема оказалась в патче на файл net/socket.c, который много лет назад был добавлен в наш репозиторий. Цель его в том, чтобы запретить клиентам использовать системный вызов bind(), это простая защита от запуска прокси-серверов клиентами. Патч свою цель выполнял, но не очищал после себя память.
Возможно, появились новые модные вредоносы на PHP, которые пробовали запустить в цикле прокси-сервер – что и привело к сотням тысяч заблокированных вызовов bind() и потерянным гигабайтам оперативной памяти.

Дальше было просто – Гавриил поправил патч и пересобрал ядро. Добавил мониторинг значения SUnreclaim на всех серверах под ОС Linux. Инженеры предупредили клиентов и перезагрузили хостинг в новое ядро.
OOM исчезли.

Но проблема с доступностью сайтов осталась
На всех серверах тестовый сайт несколько раз в день переставал отвечать.

Здесь автор начал бы рвать волосы на разных частях тела. Но Гавриил сохранял спокойствие и включил запись трафика на части хостинговых серверов.

В дампе трафика было видно, что чаще всего запрос к тестовому сайту падает после внезапного получения пакета TCP RST. Другими словами, запрос до сервера доходил, но соединение в итоге разрывалось со стороны nginx.
Дальше ещё интереснее! Запущенная Гавриилом утилита strace показывает, что демон nginx не отправляет этот пакет. Как такое может быть, ведь только nginx слушает 80-й порт?
Причиной оказалась совокупность нескольких факторов:
  • в настройках nginx указана опция reuseport (включающая опцию сокета SO_REUSEPORT), позволяющая разным процессам принимать соединения на одинаковом адресе и порту
  • в (на тот момент, самой новой) версии nginx 1.13.0 есть баг, из-за которого при запуске теста конфигурации nginx через nginx -t и использовании опции SO_REUSEPORT этот тестовый процесс nginx действительно начинал слушать 80-й порт и перехватывать запросы реальных клиентов. И при завершении процесса теста конфигурации клиенты получали Connection reset by peer
  • наконец, в мониторинге заббикса был настроен мониторинг корректности конфигурации nginx на всех серверах с установленным nginx: команда nginx -t вызывалась на них раз в минуту.
Только после обновления nginx можно было выдохнуть спокойно. График uptime сайтов пошёл вверх.

Какая мораль у всей этой истории? Сохраняйте оптимизм и избегайте использования самостоятельно собранных ядер.

timeweb.com/ru/