pCS

Мы добавили пропущенные серверы в кластер и начали копировать данные, чтобы получить по 3 копии каждого из них. Надеемся, что это будет сделано сегодня. В любом случае, как только это будет сделано, мы помещаем кластер в RO и начинаем перестраивать 30% SBG2 VPS из платной резервной копии.

25-03-2021 log sbg

Информация для клиентов:
  • SBG1: восстанавливаемые серверы Bare Metal проходят очистку, чтобы снова ввести их в эксплуатацию в Страсбурге или других центрах обработки данных к началу следующей недели (после проверки и очистки).
  • SBG3 находится в рабочем состоянии.
  • SBG4 работает: 95% серверов Bare Metal доступны для клиентов.

SBG3
  • Публичное облако:
  • + Инстанс публичного облака — 86% *
  • + Публичное облачное хранилище — перезапуск 27 марта
  • Размещенное частное облако: службы постепенно перезапускаются, в зависимости от их первоначальной конфигурации, по круглосуточному графику ротации 24/7.
  • Veeam Cloud Connect: с вечера 25 марта сервисы будут постепенно перезапускаться.
  • Baremetal Cloud
  • + VPS: 83% *
  • + Голый металл: 71% *


SBG4
  • Baremetal Cloud
  • + Чистый металл: 95% *
  • * Восстановление услуг осуществляется в соответствии с графиком перезапуска комната за комнатой, проход за проходом и стойка за стойкой. Однако требуется очистка сервера, и это определит, когда определенные стойки будут снова введены в эксплуатацию. Узнайте больше о нашем процессе очистки по этой ссылке www.linkedin.com/posts/octave-klaba-3a0b3632_update-march24-630pm-the-cleaning-takes-activity-6780540963271000064-8Q7i


SBG-1
  • Ситуация: Центр обработки данных не активирован повторно. После осмотра опытными командами технические группы могут получить доступ к комнатам.
  • Перезапуск сервера: перемещение восстанавливаемых серверов после проверки и очистки в другие наши центры обработки данных: Gravelines (GRA), Roubaix (RBX), Croix (CRX) и Strasbourg (SBG4) для возврата к работе.
  • Цель — восстановить услуги с начала недели 29 марта.

SBG-2
  • Ситуация: датацентр выключен и защищен.
  • Перезагрузка сервера: замена инфраструктуры в других центрах обработки данных: Gravelines (GRA), Roubaix (RBX), Лондон (LON), Варшава (WAW), Франкфурт (FRA)

SBG-3
  • Ситуация: Датацентр работает с 18 марта.
  • Электрический перезапуск: выполнен
  • Перезагрузка сети: завершена
  • Перезагрузка сервера: в настоящее время восстанавливаются сервисы VPS, Bare Metal и Public Cloud. Услуги размещенного частного облака будут постепенно восстанавливаться.

SBG-4
  • Ситуация: центр обработки данных работает.
  • Электрический перезапуск: выполнен
  • Перезагрузка сети: завершена
  • Перезагрузка сервера: 95% клиентских серверов Bare Metal доступны.

Обновленная информация о поставках с 10 марта:
  • Облачная вселенная:
  • — Оголенный метал
  • + Bare Metal — серверы — Количество: 6812
  • + NAS-HA — TB — Количество: 259
  • — Публичное облако
  • + VPS — VM — Количество: 15732
  • — Размещенное частное облако
  • + Хост — серверы — Количество: 723
  • + Хранилище данных
  • + Количество Zpool: 706
  • + Объем ТБ: 4079

Cloud4Y предоставил Автобюро защищённое решение для хранения персональных данных



Компания «Автобюро» работает на территории Краснодара и Краснодарского края, помогая физическим и юридическим лицам взаимодействовать с межрайонным регистрационно-экзаменационным отделом Государственной инспекции безопасности дорожного движения. Компания ускоряет и упрощает процедуру постановки транспорта на учёт, замены регистрационных знаков, оформления страховки и т.д.

В компанию обращается большое количество автовладельцев, чьи персональные данные используются при любых операциях с транспортными средствами. Поэтому «Автобюро» подпадает под требования, предъявляемые ФЗ-152. Самостоятельная закупка оборудования и строительство инфраструктуры для соответствия требованиям законодательства требует больших расходов, наличия компетентных специалистов по ИБ, а также штатных сотрудников, способных гарантировать нормальную работу всего ИТ-парка компании. Для многих компаний подобные денежные и временные траты нерациональны. Поэтому они выбирают облачные решения. Так поступили и в компании «Автобюро».

«Облака» дают возможность быстро и за разумные деньги обеспечить техническое соответствие требованиям российского законодательства в области хранения и защиты персональных данных. При выборе облака стоит отдавать предпочтение провайдерам, у которых есть аттестат ФСТЭК и ФСБ. Наличие этих документов гарантирует, что облачный провайдер исполняет требования приказа № 21 ФСТЭК, в котором прописаны технические требования к обеспечению безопасности. Кроме того, при проверке компании, размещающей ПД в аттестованном облаке, у Роскомнадзора возникает меньше вопросов. Если данные хранятся в облаке, которое аттестовано, то это значит, что всё надёжно и безопасно.

Защищённая инфраструктура Cloud4Y прошла аттестацию лицензиатами ФСТЭК и подтвердила её соответствие требованиям безопасности 1УЗ, 1Г и 1К. Поэтому, когда «Автобюро» обратилось к Cloud4Y, провайдер смог предложить выгодное и безопасное решение в рамках услуги «Облако ФЗ-152».

С помощью облачной платформы «Автобюро» удалось обеспечить должный уровень защиты персональных данных своих клиентов, избавить себя от лишнего внимания Роскомнадзора, а также сэкономить на оборудовании. Теперь компания сосредоточилась на работе с автовладельцами, поручив вопросы по хранению ПДн Cloud4Y.

Дайджест новостей за февраль

Финансовые итоги 2020 года
В 2020 году выручка платформы Yandex.Cloud увеличилась в 4,5 раза и достигла 1 миллиарда рублей. Количество коммерческих клиентов Yandex.Cloud выросло по сравнению с 2019 годом в 1,4 раза и составило 9 700, а средний чек одного клиента увеличился за этот период в 3 раза.

Мы подробно рассказали про развитие платформы Yandex.Cloud в 2020 году, наших финансовых показателях, а также об особенностях спроса и потребления облачных сервисов платформы в отдельном посте.


Решения на сайте
Мы запустили на сайте раздел Решения. Собрали в нём популярные задачи и отрасли, которые используют сервисы и технологии Yandex.Cloud, и рассказали, как они помогают решать задачи бизнеса.
Сейчас на сайте 15 решений: для отраслей — среди них ритейл, финансы, образование — и для популярных задач, например, миграции в облако, визуализации данных и автоматизации колл-центров.
Мы будем развивать раздел: добавим новые руководства, записи вебинаров, кейсы клиентов, чтобы вы лучше ориентировались в возможностях Yandex.Cloud и быстрее находили решения для ваших задач.
cloud.yandex.ru/solutions

Yandex Tracker в Yandex.Cloud
С 1 марта Yandex Tracker становится частью Yandex.Cloud. Tracker — это универсальный сервис для командной работы, распределения ресурсов и контроля выполнения задач внутри компаний. После присоединения к облачной платформе в нём появятся новые возможности для корпоративных клиентов, среди них — подключение федерации удостоверений в Yandex.Cloud.
Федерация удостоверений позволит авторизоваться в Tracker через корпоративную учётную запись, по технологии единого входа SSO (Single Sign-On). Для компаний, использующих корпоративные системы управления пользователями, например Active Directory, это упростит администрирование доступов сотрудников. Клиенты, уже работающие с облачной платформой, смогут подключить Tracker к своей учётной записи и оплачивать сервис с единого платёжного аккаунта.

Новый сервис Yandex Application Load Balancer
На платформе Yandex.Cloud появился сервис Yandex Application Load Balancer для создания масштабируемых управляемых балансировщиков HTTP-трафика. Сервис берёт на себя маршрутизацию трафика с учётом HTTP-запросов и заголовков, терминирование TLS и обеспечение безопасности соединений между компонентами приложений.
C Application Load Balancer вы можете создавать масштабируемые L7-балансировщики для распределения HTTP-трафика и управлять ими в консоли управления или с помощью CLI.
Сервис сетевых балансировщиков теперь называется Yandex Network Load Balancer.
cloud.yandex.ru/blog/posts/2021/02/application-load-balancer-preview

Блог в Яндекс.Дзене
Мы запустили блог в Яндекс.Дзене и начали собирать в нём полезные статьи об облаках для бизнеса, реальные кейсы клиентов, ликбезы по нашим сервисам, мнения экспертов Yandex.Cloud и новости облачной индустрии и IT в целом.
zen.yandex.ru/yandexcloud

Новости сервисов
Yandex Database

Добавлена инструкция по использованию AWS CLI и AWS SDK для работы с базой через Document API. Протестируйте использование Yandex Database в serverless-режиме бесплатно по программе — free tier.

Managed Service for PostgreSQL
Добавлена поддержка управления группами безопасности в консоли управления, CLI и с помощью Terraform.
Добавлены команды yc managed-postgresql cluster create, yc managed-postgresql cluster update и yc managed-postgresql cluster restore.
Для флага --postgresql-version string добавлено значение 13 для создания кластера PostgreSQL версии 13.

Новые образы в Marketplace
Сделали обновление образов на базе Linux с исправлением ошибок «CVE-2021-3156 — Privileges escalation via sudo»:
  • Ubuntu 16.04 LTS GPU;
  • openSUSE 15.2;
  • 1С: ​​​Предприятие 8.3.

Публикации в СМИ
IT-бизнес RussiaRunning

В нашем блоге на vc.ru рассказали про проект RussiaRunning. Компания монетизировала и масштабировала один из ИТ-проектов для спортивных мероприятий с помощью облачных технологий Yandex.Cloud.
vc.ru/life/210844-kak-my-prevratili-semeynye-zabegi-v-it-biznes

Студенты из Бауманки сделали беспилотный гоночный болид
В статье на vc.ru рассказываем, как студенческая команда МГТУ им. Н. Э. Баумана одной из первых в России проектирует беспилотный гоночный электроболид для международных соревнований, а нейросети и облачные технологии помогают им на поворотах.
vc.ru/transport/204818-driverless-po-studencheski-kak-komanda-iz-baumanki-razrabatyvaet-bespilotnyy-gonochnyy-bolid

Как анализировать до 100% звонков
Никита Ткачёв в статье для vc.ru рассказал, как мы в Yandex.Cloud совершенствуем технологии автоматического распознавания речи, которые позволяют нашим пользователям транскрибировать звонок с минимальной задержкой и с точностью до 97%.
vc.ru/yandex.cloud/203019-kak-analizirovat-do-100-zvonkov-ot-vashih-klientov-ne-razduvaya-byudzhet

Истории успеха
Как Yandex.Cloud помогает «АльфаСтрахованию» ускорять бизнес

Группа «АльфаСтрахование» — крупнейшая российская частная страховая компания, в портфеле которой более 100 цифровых продуктов для бизнеса и частных клиентов. Для развития им потребовалась новая инфраструктура с возможностью гибкого масштабирования и платформенные сервисы.
Yandex.Cloud помог «АльфаСтрахованию» сократить время вывода новых продуктов на рынок с одного года до 1‑3 месяцев, уменьшить расходы на инфраструктуру — на некоторых проектах до 30% ожидавшихся затрат, а также расширить экспертный опыт сотрудников.
cloud.yandex.ru/cases/alfastrah

Всероссийская олимпиада школьников в Yandex.Cloud: 24 предмета и более 320 тысяч уникальных пользователей
Компания «Цифровое образование», используя технологии Yandex.Cloud, впервые провела школьный этап Всероссийской олимпиады школьников в Московской области онлайн. Новый формат позволил охватить большое количество школьников: более 320 тысяч учащихся решили 1,2 миллиона олимпиад. Нагрузку в начале олимпиады было сложно предсказать, но облачная инфраструктура позволила гибко масштабироваться. Сервис работал стабильно даже в моменты пиковых нагрузок.
cloud.yandex.ru/cases/talenttech

Мероприятия в марте
В марте мы уже провели Cloud Day для сферы образования, где рассказали об опыте использования облачных сервисов. Обязательно регистрируйтесь на вебинары Настройки ролевых моделей и политик для Managed Service for Kubernetes, Работайте над проектами, как в Яндексе про нашу работу в Yandex Tracker, участвуйте в митапе about: cloud — всё о Платформе данных и других.
cloud.yandex.ru/events/342
cloud.yandex.ru/events/304
cloud.yandex.ru/events/337
cloud.yandex.ru/events/339

Прошедшие вебинары
Безопасность в инфраструктуре, основанной на Kubernetes

Обсудили набор практик, которые минимизируют риски простоя production-среды из-за человеческих ошибок, при этом сохраняя self-service модель для разработчиков, за которую так ценят Kubernetes.
cloud.yandex.ru/events/302

Java в serverless — быть или не быть?
Рассказали про этапы создания serverless-рантайма для Java. Как устроен рантайм, каковы его сильные и слабые стороны и как с его помощью переносить почти любые Java-приложения в serverless. Запись вебинара поможет вам создавать собственные serverless-приложения.
cloud.yandex.ru/events/300

Возможности речевой аналитики для бизнеса
Как анализировать 100% информации 24/7 и всегда держать руку на пульсе коммуникаций компании, как изменить отдел клиентского сервиса, анализировать намного больше коммуникаций с клиентами и значительно улучшить показатели контакт-центра. Смотрите вебинар про главные тренды в речевой аналитике.
cloud.yandex.ru/events/303

Новое в Yandex DataSphere для ML-разработки
Рассказали о том, как получить доступ к режиму Early Access Version, как использовать индикацию загрузки памяти и CPU, TensorBoard и новые фоновые операции. И конечно, поделились планами по развитию Yandex DataSphere на ближайшие месяцы.
cloud.yandex.ru/events/301

Безопасная обработка данных платёжных карт в Yandex.Cloud
Обсудили особенности PCI DSS и разделение ответственности в облачных сервисах. Рассмотрели ситуации, когда PCI DSS необходим, а когда можно обойтись без него. Показали примеры реализации инфраструктуры клиента, соответствующей стандартам PCI DSS.
cloud.yandex.ru/events/299

Onrealt: масштабируемая инфраструктура для сайта недвижимости

Меня зовут Лев, я главный администратор сайта объявлений о продаже и аренде недвижимости Onrealt. Хочу поделиться впечатлениями о сотрудничестве с компанией FirstDEDIC.
onrealt.ru



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

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

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

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

Как мы выбирали хостера
Перед нами стоял выбор среди множества компаний, предоставляющих услуги аренды оборудования. При выборе мы опирались на следующие критерии.
  • Оптимальное соотношение цены и качества.
  • Стабильная работа оборудования.
  • Возможность выбора гибкой конфигурации серверов, каждый из которых необходим для решения определённых задач.
  • Быстрое подключение новых серверов.
  • Подключение серверов в локальную сеть.
  • Отзывчивая и компетентная техническая поддержка.
Изучив рынок, мы выбрали FirstDEDIC. Конечно, по отзывам сложно удостовериться в том, что компания соответствует всем критериям, но мы решили попробовать и, как выяснилось позже, не ошиблись.

Наша инфраструктура
Изначально мы арендовали 5 серверов. Все серверы были объединены в VLAN (виртуальная локальная сеть) для конечной реализации нашей структуры.


Сервер для работы с базами данных
На данном сервере разместили основные базы данных — MySQL и Memcached для хранения сессий. Чтобы надёжно хранить большой объём данных и быстро с ним работать, мы выбрали следующую конфигурацию: два процессора E5-2620v4 2.1-3.3 ГГц (8 ядер), 256 Гб оперативной памяти, два SSD 1920 Гб в зеркальном рейде.

Сервер для репликации базы данных и бекапов
Основная задача данного сервера — хранение резервной копии базы данных и репликация части таблиц для оптимизации выборок MySQL.

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

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

Основной веб-сервер
Задача данного сервера — обработка входящих запросов к сайту и к API для приложений.

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

Сервер для хранения файлов
Наш сайт содержит множество объявлений, а объявления в свою очередь — много фотографии. В итоге нам необходимо хранить внушительный объём файлов.

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

Чего мы добились
Наш сервис был запущен в конце декабря 2017 года, а уже в 2018 году ежемесячная посещаемость выросла до 900 тысяч. В 2019 году — до 1,6 млн, в 2020 уже до 2,4 млн уникальных посетителей в месяц.


Это стало возможно в том числе благодаря тому, что наша серверная инфраструктура предусматривала возможность масштабирования. На протяжении сотрудничества с FirstDEDIC количество арендуемых серверов увеличилось с 5 до 15.

Все наши ожидания были оправданы, оборудование работает стабильно. Если возникают какие-либо проблемы, сотрудники компании сразу сообщают нам об этом — в большинстве случаев еще до того, как мы сами обнаружим проблему.

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

https://firstdedic.ru

Интернет-магазин 1HMM: Три жизненных урока, которые мы получили, пока искали подходящего хостинг-провайдера

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

Один из таких клиентов — Антон Кинстлер, руководитель IT-отдела интернет-магазина мебели «1HMM». И сегодня он расскажет о том, с какими трудностями столкнулась его команда, когда компания решила выйти в онлайн, и какие жизненные уроки из этого вынесла.
1hmm.ru


Предыстория
Наша история началась с маленького магазинчика в городе Верхний Уфалей Челябинской области. В 2011 году был открыт оптовый склад в Челябинске, в 2013-м создали интернет-магазин, а в апреле получили первый заказ через него. Это был многостраничный сайт на 1С-Битрикс: Управление сайтом редакции «Бизнес», и в тот момент на него было заведено около тысячи позиций.

Постепенно интернет-магазин развивался — мы добавляли десятки тысяч новых товаров, оптимизировали сайт, стали использовать такие технологии, как Redis, ElasticSearch, RabbitMQ. Сейчас на сайте свыше 200 тысяч товарных позиций, более тысячи личных кабинетов оптовых покупателей и партнеров, а также десятки миллионов цен.


Сайт интернет-магазина сегодня. Ежедневно его посещают до 50 000 человек
Вообще у нас интересная система. Кроме привычной механики личного кабинета для розничных покупателей и франчайзи, мы реализовали готовый инструмент продаж для наших оптовых покупателей. На базе нашей системы они могут кастомизировать предложенный шаблон, разместить его на своем домене, поставить на товары свои цены, изменить дизайн, добавить свои реквизиты. То есть по факту каждый наш оптовый покупатель получает свой полноценный интернет-магазин, который актуален по ассортименту, остаткам, ценам. И при этом вся работа поддерживается нашими отделами.

Естественно, с ростом проекта требования к серверной инфраструктуре менялись. За семь лет мы успели поработать с разными хостинг-провайдерами, меняли серверы и не раз сталкивались с разными сложностями, которые только добавляли нам опыта. И сегодня я расскажу о трёх уроках, которые кое-чему научили нас за это время.

Урок первый. Как мы просчитались с ресурсами
На старте у нас не было большого трафика на сайт, и мы решили использовать недорогой виртуальный хостинг в Екатеринбурге. Что мы не учли, так это «тяжесть» самого проекта. Дело в том, что помимо большого ассортимента у нас на каждый регион — так исторически сложилось — свой тип цены. Соответственно, у нас десятки миллионов цен (предложений). Поэтому, несмотря на небольшой трафик, мы почти сразу упёрлись в потолок виртуального хостинга. Сайт тормозил, страницы открывались медленно, мы теряли клиентов и деньги. Пришлось срочно «переобуваться» и искать другие варианты.

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

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

Вывод — заранее закладывайте запас по ресурсам
«Переезжать» к новому хостеру каждый раз, когда вы упираетесь в нехватку ресурсов, дело не самое простое – особенно, если у вас большое количество данных. Поэтому теперь мы заранее прикидываем, как будет расти проект и сможет ли провайдер быстро и без проблем добавить нам мощностей при необходимости. Инфраструктура у нас удваивается практически ежегодно, потребности растут — более 50 тысяч посещений ежедневно, а если по хитам смотреть, то по 10 на каждого.

Сейчас у нас нет проблем с масштабированием — просто пишем в поддержку, что нам нужен еще один сервер, и его поднимают.

Урок второй. На хостера надейся, а сам не плошай
Как я уже говорил, какое-то время мы размещали сайт у немецкого хостера, пока он не разочаровал нас. Было несколько остановок, деградировали жесткие диски. На серверах, которые мы арендуем, работает сам интернет-магазин, розничные магазины, франчайзи, партнеры и оптовые покупатели — остановка даже на несколько часов влияет на всех. В сутки мы получаем порядка 1200 заказов. Соответственно, час простоя обходится в потерю примерно ста клиентов. Поэтому для нас так важно, чтобы серверы работали без перебоев.

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

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

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

Урок третий. Сервис с человеческим лицом
Был у нас и такой случай. Довольно долгое время мы хостились у одного из топовых российских провайдеров. Никаких нареканий в техническом плане. И всё шло хорошо, пока мы не столкнулись с проблемой совсем другого характера.

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

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

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

https://firstdedic.ru

Управляемые базы данных: сравнение стоимости с on‑premise и самостоятельной установкой в облаке



Мы покажем, как они помогают сократить нагрузку на персонал, сэкономить деньги и сосредоточиться на задачах бизнеса. В конце статьи приведем расчеты, сколько стоит владение каждым из вариантов: on-premise, виртуальной машиной (ВМ) в облаке и управляемой базой данных (БД).

Установка и первоначальная настройка
Жизненный цикл любой БД начинается с установки. Но перед этим необходимо подготовить инфраструктуру: оборудование, операционную систему (ОС), сеть, политики безопасности, пользователей и т. д. С одной стороны, это разовое действие, с другой, если через месяц для нового проекта понадобится БД — все придется делать заново.

Управляемая БД разворачивается по нажатию нескольких кнопок: нужно выбрать тип, задать параметры ВМ (CPU, RAM и др.) и подождать несколько минут. Шаги для развёртывания баз данных при самостоятельной установке или с управляемой БД:


Поддержка специалистами
После установки сразу начинается этап поддержки. Нужно непрерывно следить за оборудованием, ОС и самой БД. Оборудование нуждается в бесперебойном питании, мониторинге и периодической замене. Необходимо регулярно устанавливать обновления ОС и БД, чтобы исправлять ошибки и закрывать уязвимости. Поддержка продолжается постоянно, на нее уходит время.

Отдельно стоит упомянуть мажорные обновления ОС и системы управления базами данных (СУБД). Время от времени нужно переходить на новые версии, но компании обычно откладывают миграцию на последний момент или вовсе продолжают работать с неподдерживаемыми версиями. Потому что самостоятельное обновление и миграция — это долго и сложно: нужно учесть много нюансов, провести тестирование и решить возникающие проблемы.

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

В крупных компаниях есть администраторы, которые занимаются только БД. Это опытные специалисты, и у них достаточно знаний и умений, чтобы решать проблемы в сроки, определенные в SLA.

Примечание
Команда Yandex.Cloud не просто администрирует БД, мы также получаем опыт из разработки. Системные администраторы и разработчики совместно улучшают БД: решают инциденты и совершенствуют сам сервис.
  • Мы разработали ClickHouse — высокопроизводительную аналитическую БД, которая обрабатывает миллиарды строк в секунду. Мы создавали ее для внутренних задач, а сейчас ею пользуются более 2000 компаний по всему миру: в e-commerce, мобильной и игровой разработке, рекламе и аналитике.
  • Мы участвуем в разработке других открытых проектов. Например, мы создали пулер соединений Odyssey для PostgreSQL, участвуем в развитии системы бекапирования WAL-G и других расширений для PostgreSQL.
  • Мы используем управляемые БД внутри собственных продуктов: Почты, Такси, Диска, Драйва и др. Поэтому мы понимаем на деле, какие проблемы возникают у пользователей управляемых БД, и стараемся сами их решать.

В управляемом сервисе поддержкой занимается облачный провайдер, а клиенту нужно только управлять пользователями. Мы сами следим за оборудованием, ОС и БД; устанавливаем обновления, сопровождаем системы мониторинга, резервное копирование и сетевые настройки. За базами следят профильные специалисты, которые работают с ними каждый день. Они понимают, как устроены БД, следят за развитием технологий и последними новостями. Поэтому их решения — оптимальные и соответствуют лучшим практикам. Профильные специалисты знают, как лучше настроить БД, как реализовать ту или иную функцию, и помогут советом, если вы столкнетесь с нестандартной ситуацией.

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

Ниже перечислены задачи обслуживания БД при самостоятельном администрировании и при использовании сервиса по управлению базой данных.


Отказоустойчивость и масштабируемость
Отказоустойчивость СУБД достигается за счет создания кластера: если из строя выйдет один из хостов, остальные продолжат работу. В идеале хосты следует расположить в разных ЦОДах (зонах доступности), обезопасить свой проект от сбоев целого дата-центра.

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

Схема построения отказоустойчивого кластера:


Управляемые БД — это отказоустойчивость и легкое изменение топологии из коробки. Все наши БД кластерные, и для любой можно создать реплики в трех зонах доступности. Это повышает отказоустойчивость и позволяет легко масштабировать кластер. Например, вы разворачиваете стенд для нового проекта, который еще разрабатывается. Поначалу проекту не нужны реплики, так как к нему не предъявляются требования продуктивных систем. Но когда проект готов к запуску в production, вы можете из этой БД сразу же сделать боевую отказоустойчивую систему. Добавляете реплики к установке и получаете отказоустойчивую БД без переноса данных и миграции.

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

В управляемой БД все задачи, кроме расписания, решает облачный провайдер. Восстановить копию можно самостоятельно несколькими кликами мыши — не придется писать в поддержку и ждать ответа.

Кроме привычных всем бекапов, в некоторых СУБД есть механизм point-in-time recovery (PITR). Эта полезная функция позволяет восстановить данные на любой момент, а не только на момент создания копии. Например, бекап создается ночью в 00:00. Утром БД начинает наполняться данными, а в обед junior-разработчик случайно удаляет одну из таблиц. Если восстановить предыдущую копию — то потеряются утренние данные. Механизм PITR позволяет указать точное время, на которое нужно восстановить данные: он сам восстановит последнюю копию и применит все транзакции, которые прошли после ее создания.


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

Полностью управляемый сервис, а не ВМ с шаблоном
Мы предоставляем полностью управляемые БД: вы получаете доступ к БД как пользователь, а мы следим, чтобы она работала как часы. Вы создаете схемы и таблицы, обращаетесь к данным, анализируете производительность запросов. Но у вас нет root-доступа, вы не можете менять системные настройки и управлять ВМ, на которой запущена СУБД.

Кажется, что вы получаете меньше гибкости, ведь вы не можете управлять всеми настройками. Но чаще всего клиентам нужна готовая и стабильная БД, а не конструктор, который легко сломать. Именно благодаря таким ограничениям мы гарантируем стабильную работу СУБД.

Есть и другой вариант: пользователи получают полный доступ к СУБД и ВМ, на которой она работает. Это нельзя назвать полностью управляемым сервисом, это скорее ВМ с готовым шаблоном для быстрого развертывания БД. Такой вариант упрощает установку и настройку. Но раз вы имеете доступ ко всем внутренним настройкам и функциям — провайдеру сложнее гарантировать стабильную работу. Если из-за вмешательства система сломается, провайдер не отвечает за это и разбираться придется самостоятельно.

В Yandex.Cloud вы получаете на 100% управляемый сервис. А еще мы единственный облачный провайдер в России, у которого есть Terraform для управляемых БД. Через него можно делать все то же самое, что через консоль управления, API и CLI.

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

Примеры графиков мониторинга — потребление ресурсов, количество запросов и другие:


Кроме самих метрик еще есть алерты — удобный способ узнать о приближении к критической отметке. Например, когда заканчивается место в БД или появляются запросы с ошибками.

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

Доступность выше, чем у ВМ
Еще одна особенность управляемых БД — соглашение об уровне сервиса (SLA). Мы гарантируем, что БД будет доступна определенное количество времени. Если мы не выполним обещание, то компенсируем вам стоимость сервиса.


Чтобы добиться такой доступности своими силами, нужно потратить много времени и сил. И если не получится и БД все-таки будет долго простаивать — вам это никто не компенсирует.

При аренде БД на ВМ провайдер также гарантирует доступность по SLA. Но, как правило, SLA для ВМ ниже, чем для управляемой БД. Например, наше SLA для ВМ — 99,95%. Когда ВМ простаивает, это означает, что БД недоступна на чтение и на запись. А в управляемой БД эти операции разделены, и если БД недоступна на запись, то вполне вероятно, что она доступна хотя бы на чтение благодаря репликам.

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

Компания MongoDB, наш партнер, описала все действия, на которые расходуется время в различных моделях развертывания БД: на своем оборудовании, на облачной ВМ и полностью управляемой БД. На схеме видно, что в управляемых БД практически все время уходит на разработку и инновации, т. е. на решение конкретных задач бизнеса, а не на настройку и обслуживание БД.


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

Сосредоточиться на задачах бизнеса также помогает интеграция с другими сервисами, например с сервисом визуализации данных Yandex DataLens. Это инструмент для визуализации данных: таблиц, графиков и карт. С его помощью можно быстро проверить гипотезу или собрать полноценный дашборд с показателями компании. DataLens бесплатен для пользователей управляемых БД.

Сколько это стоит
Мы посчитали стоимость владения и управления тремя видами ресурсов: on-premise, ВМ на базе Yandex Compute Cloud и сервисом по управлению базами данных. Мы выбрали эквивалентное по мощности оборудование и сравнили, сколько это стоит в каждом из вариантов.

Расчеты приведем на горизонте трех лет, т. е. амортизацию оборудования в on-premise-решении посчитаем за три года.

Это упрощенный расчет: мы не учли несколько моментов. Например, что в on-premise решении оборудование можно продать после использования, а отсутствие капитальных затрат в управляемой БД можно инвестировать в другие направления бизнеса. Более подробный расчет мы сделаем в отдельной статье.

Сравнение стоимости управления и владения различными вариантами работы с БД:


On-premise требует больше всего времени, денег и усилий, потому что вам придется:
  • Заниматься оборудованием: покупать его, следить за ним, поддерживать бесперебойную работу и периодически менять, когда оно устареет или сломается. Если проект развивается, то со временем мощности станет недостаточно и потребуется новое оборудование. Если же сразу взять мощность с запасом — оборудование будет простаивать.
  • Пример: сервер HP с 12 ядрами стоимостью ≈ 800 000 ₽. С учетом амортизации за три года получается ≈ 22 000 ₽ в месяц.
  • Согласно исследованию некоммерческой организации NRDC, утилизация on-premise оборудования от трех до четырех раз ниже, чем облачного. С учетом данной поправки стоимость владения оборудованием составит как минимум ≈ 22 000 × 3 = ≈ 66 000 ₽ в месяц.
  • Искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому для примера примем, что на администрирование БД они тратят только 50% времени.
  • Зарплата специалиста — ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.
  • Итого ≈ 196 000 ₽ в месяц.

ВМ на базе Compute Cloud стоит дешевле и требует меньше усилий
  • Не нужно заниматься оборудованием: за ним следим мы.
  • Стоимость развертывания ВМ в Yandex.Cloud — ≈ 27 500 ₽ в месяц.
  • Нужно искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому для примера примем, что на администрирование БД они тратят только 50% времени.
  • Зарплата специалиста — ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.
  • Итого ≈ 157 500 ₽ в месяц.
Управляемая БД требует меньше всего усилий и денег, потому что вам не нужно:
  • Заниматься оборудованием.
  • Искать сотрудников для администрирования БД. Ваши специалисты могут сосредоточиться на развитии продукта. Для вас неважно, сколько человек администрируют базу, когда они уходят в отпуск и кто кого подменяет: мы решаем эти вопросы сами.
Пример: управляемая БД (24 vCPU, 96 RAM, 240 ГБ SSD) стоит ≈ 42 000 ₽ в месяц.

Итог: экономия от управляемыми БД по сравнению с on-premise может доходить 80%, а по сравнению с ВМ на базе Compute Cloud до 70% (в основном за счет персонала).

Краткий вывод
В статье мы рассмотрели преимущества управляемых БД перед самостоятельным развертыванием в on-premise и в ВМ.
Сервис по управлению базами данных на платформе Yandex.Cloud позволяет:
  • Упростить установку, настройку и сопровождение системы;
  • Подключить дополнительные инструменты, например систему мониторинга или визуализации данных;
  • Экономить по сравнению с решениями on-premise и на базе ВМ, в основном за счет персонала и оборудования;
  • Быстрее тестировать гипотезы и разрабатывать новые продукты, подключая необходимые ресурсы по клику и снижая время на time-to-market (запуск новых продуктов на рынок).

Устранение конкретного заблуждения относительно межсетевого взаимодействия



С 2014 года Qrator Labs разрабатывает сервис BGP-мониторинга и аналитики под названием Qrator.Radar. Одна из его основных функций — мониторинг определенных аномалий BGP, которые могут привести к инциденту, который мы в дальнейшем будем называть либо утечкой маршрута BGP, либо захватом BGP.

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

Наша компания начала собирать модель отношений BGP за пару лет до появления RFC 7908, пытаясь определить, что такое утечка маршрута BGP. Два основных различия между этими временами событий были описаны как:
  • Маршруты перенаправляются через неправильные ASN / ссылки (утечки маршрутов), описываются как типы 1-4 RFC 7908;
  • Маршруты перенаправляются на неправильные ASN (Hijack), описанные как типы 5 и 6 RFC 7908.
Во время утечки маршрута BGP трафик, предназначенный для вашей сети, скорее всего, будет проходить неэффективно, что может привести к увеличению задержки в сети и потере пакетов. Тем не менее, он почти наверняка достигнет вашей сети, если по какой-либо причине нет критической перегрузки сети (например, из-за плохого намерения сбоя).

Во время перехвата BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и остается там.

Более того, механизмы создания аномалий такого типа также различны. Чтобы создать утечку маршрута, вам необходимо передать хороший маршрут неподходящему соседнему интернет-провайдеру. Чтобы создать захват, вам нужно либо объявить маршрут с субпрефиксом / более конкретным допустимым префиксом (чтобы привлечь весь трафик от интернет-провайдеров, которые получили такое объявление с любым AS_PATH, который вам нравится), либо создать объявление маршрута с сторонний префикс из вашей сети.

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

Чтобы обнаружить причину утечки маршрута, вам необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и выяснить такие маршруты BGP (от сборщика BGP), которые нарушают формальную модель Гао-Рексфорда, для получения дополнительной информации см. с «отношениями AS» CAIDA.
Чтобы обнаружить угоны, вам необходимо знать, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префиксов интернет-провайдера — создайте сигнал тревоги или примите меры.
www.caida.org/data/as-relationships/

Чтобы предотвратить / смягчить захват, существует два стандартных подхода в рамках единой структуры проверки происхождения префикса. Вы можете зарегистрировать объект Route в IRR или создать объект ROA. Наша команда описала различия между этими подходами во время RIPE79. Однако общее — они оба указывают, какие префиксы принадлежат каким операторам (самими операторами), и пытаются заблокировать маршруты от интернет-провайдера с незарегистрированными префиксами (транзитными интернет-провайдерами).

Чтобы предотвратить / смягчить чистые утечки маршрутов, мы принимаем участие в создании открытой политики BGP. Другой подход — одноранговая блокировка — блокировка маршрутов с неожиданными соседями / интернет-провайдерами в AS_PATH.
datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/
archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf
datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/

Проект ASPA IETF стоит немного в стороне от чистого предотвращения перехвата / утечки маршрутов, потому что он больше касается блокирования плохих AS_PATH (случаев утечки маршрутов и перехватов без / с плохой манипуляцией AS_PATH).

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

Подписание ROA против фильтрации ROA
Еще одно распространенное заблуждение связано с РОА. В алгоритмах ROA есть две стороны: подписывающая сторона — оператор, который предоставляет достоверную информацию о принадлежащих ему префиксах; и есть фильтрующая сторона — транзитный оператор, который отфильтровывает плохие маршруты в соответствии с информацией, предоставленной подписавшей стороной.

Как оператор-заглушка (то есть автономная система только с одним вышестоящим провайдером), вы ограничены в количестве способов, которыми вы можете влиять на количество фильтрующих сторон. Чем их больше, тем более безопасными будут ваши префиксы (меньше регионов будет затронуто, если угонщик решит атаковать ваши префиксы). Если вы решите подписать свои префиксы, вы можете использовать существующую инфраструктуру фильтрации, которая в ближайшем будущем будет только расти. Более того, мы рекомендуем вам делать именно это в любом случае, то есть независимо от размера сети, стоящей за вашим ASN.

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

pCS

Мы успешно очистили достаточно дисков для метаданных. Теперь мы можем восстанавливать кольца. Фото: до vs после.

У нас есть 20% данных всего с одной копией. Сначала мы восстанавливаем избыточность данных. Затем мы даем доступ RO. Потом RW.