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



Открыли возможность создавать облачные серверы в Москве. И вместе с этим опцию создавать их без 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

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



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

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



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

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

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

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

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

timeweb.com/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/

Апгрейд 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/