PS Cloud Services [PS.kz]

Добавление репозиториев на mirror.ps.kz

В продолжение темы локальных зеркал: нас спросили, можем ли мы расширить стандартные репозитории Linux-дистрибутивов, в частности — Ubuntu для ARM.

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

Обратите внимание, что мы не реплицируем частные репозитории. Объемные дистрибутивы порядка нескольких терабайт публикуем только в том случае, если накопится достаточное количество заявок.

Пишите письма на [email protected]

P.S. Кстати, про ARM накопились вопросы, скоро зададим.

Вы установили SSL-сертификат?

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

Просто напоминаем, что есть бесплатные сертификаты Let's Encrypt. Это проект Linux Foundation, его главная идея в том, чтобы сделать шифрование доступным для всех.

У нас SSL-сертификат Let's Encrypt включен в услуги:

✓ «Конструктор сайтов» — сертификат устанавливается автоматически;
✓ «Хостинг сайтов» и «Хостинг для CMS 1С-Битрикс» — установите по инструкции;
✓ «VPS-хостинг» — читайте инструкцию;
✓ «Virtuozzo Application Platform» — описано здесь.

Сертификат выдается на 3 месяца и продлевается автоматически в течение всего периода использования услуги.

Если вас интересуют SSL-сертификаты с расширенным функционалом, загляните сюда. Мы недавно запустили новую линейку от бренда GoGetSSL по демократичным ценам.

При создании облачного сервера (на Ubuntu 20/22, Debian 10/11, AlmaLinux 8) мы предлагаем предустановку приложений. Это позволяет быстро развернуть рабочие среды и сэкономить время на их настройке. Наиболее широкий выбор приложений представлен на Ubuntu 20.04 LTS:

— LAMP (Apache, PHP, MySQL/MariaDB, PhpMyAdmin, SFTP, Fail2Ban, Let's Encrypt);
— LAMP + Nginx;
— LEMP (Nginx, PHP, PHP FPM, MySQL, PhpMyAdmin, SFTP, Fail2Ban);
— Node.js (Nginx, Node.js, MongoDB, Express, Angular);
— Django (Nginx, Python, uWSGI);
— Docker Compose;
— Plesk или ispmanager (лицензии на панели приобретаются отдельно).

На CentOS 7.9 есть возможность предустановки 1C-Битрикс (веб-окружение, SFTP).

Если у вас есть пожелания, как расширить этот список, проголосуйте в опросе ниже или напишите сюда свой вариант.

Возможные конфигурации облачных серверов

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

1. Высокочастотные (флейвор f1)

На базе Intel Xeon E-2288G 3.7 GHz, 100% использование ресурсов. Конфигурация подходит для выполнения однопоточных задач с минимальным временем отклика: 1С, Битрикс24, базы данных, OLTP-приложения.

2. Высокочастотные + (флейвор f2)

Intel Xeon E-2388G 3.20 GHz с гарантированным использованием всех ресурсов. Подходит для CRM-систем, баз данных и веб-приложений с активным пользовательским взаимодействием.

3. AMD (флейвор a1)

AMD Ryzen 9 7950X 4.5 GHz, также с полным использованием ресурсов. Конфигурация отличается высокой производительностью и предназначена для многозадачных приложений (виртуализации, рендеринга, стриминга и прочих).

4. Bare metal (флейвор i1)

Физические серверы без виртуализации (на базе Intel Xeon E5-2699 v4 2.20 GHz, E5-2680 v4 2.30 GHz, E5-2620 v3 2.40 GHz). Конфигурация обеспечивает высокую производительность и безопасность, оптимальна для крупных корпоративных баз данных и финансовых приложений.

5. Общего назначения (флейвор d1)

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

А еще мы тестируем линейку конфигураций с GPU (NVIDIA RTX A2000, Tesla T4, RTX 2080 Super, RTX A4000 и др.) для интенсивных вычислений. Если вы занимаетесь машинным обучением или обработкой графики, обращайтесь: [email protected]

Локальные зеркала Linux-дистрибутивов в Казнете от PS.KZ

Друзья, сегодня делимся полезной информацией для тех, кому важна скорость. Уже много лет мы поддерживаем локальные зеркала для большинства Linux-дистрибутивов: Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, Alpine, Fedora и многих других. Мы находимся в списках рекомендованных зеркал нашего региона на официальных сайтах различных дистрибутивов.

Настройка локальных зеркал позволит ускорить обновление систем в несколько раз. Наше публичное зеркало находится по адресу ➡️https://mirror.ps.kz/

🛸PS: Локальные зеркала серверов — это копии репозиториев, созданные для повышения скорости доступа к основным серверам обновлений. Локальные зеркала повышают отказоустойчивость, предоставляя доступ к данным в случае недоступности основных зеркал.

Помогаем мигрировать в Kubernetes

Вышел пресс-релиз CNCF с упоминанием PS Cloud Services в перечне новых партнеров. Напоминаем, что в этом году мы получили статус «Kubernetes Certified Service Provider» и Silver Member в организации CNCF, развивающей Kubernetes и другие Open Source-проекты. Несколько инженеров нашей компании, оказывающих платную техподдержку в рамках услуги «Администрирование серверов», являются обладателями сертификатов «Certified Kubernetes Administrator».

Что означает наш новый статус на практике — рассказываем на примере свежего кейса.

Один наш клиент «вырос» из традиционной серверной архитектуры и искал решение, которое позволило бы динамически масштабировать приложения и минимизировать простой при обновлениях и сбоях. Мы предложили мигрировать в Kubernetes, что позволило бы клиенту добиться необходимых целей по масштабируемости, отказоустойчивости и автоматизации процессов. Процесс работы включал в себя:

1. Аудит и документирование текущей инфраструктуры
Мы провели полный анализ всех сервисов и их взаимодействий. Это дало нам чёткую картину того, какие приложения требуют доработки перед переносом в Kubernetes.

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

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

4. Контейнеризация приложения
Мы распределили приложения по контейнерам для легкого управления его развёртыванием и обновлениями.

5. Проектирование системы логирования и мониторинга
Мы внедрили централизованную систему сбора логов и мониторинга Grafana + Loki + Promtail, что позволило клиенту отслеживать все процессы в реальном времени и быстро реагировать на возможные сбои.

6. Автоматизация CI/CD
Настроили автоматизированные процессы развертывания и тестирования приложений с помощью ArgoCD, что значительно ускорило цикл релизов.

7. Создание манифестов Kubernetes
Для каждого сервиса были разработаны манифесты для деплоя в кластер. Мы провели тестирование развертываний, убедившись в их стабильности.

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

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

Результат

После успешного завершения миграции клиент получил систему, которая полностью отвечает его требованиям по отказоустойчивости и масштабируемости. Теперь его разработчики могут:

1. Автоматически разворачивать новые версии приложений с помощью ArgoCD.
2. Откатываться к предыдущим версиям без длительных простоев.
3. Динамически масштабировать приложения в зависимости от нагрузки с помощью Horizontal Pod Autoscaling.
4. Автоматически поддерживать необходимое количество копий приложений и перезапускать их в случае сбоя.

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

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

Друзья, на этом турне Антошевского не заканчивается. Уже в субботу он выступит на Open SysConf 2024 с докладом «Три системы, которые ты захочешь развернуть и настроить».

Конференция Open SysConf — это местный IT-андеграунд (по меткому выражению коллег из Profit) и наш давний партнер. Регистрация открыта, присоединяйтесь.

Когда: 12 октября, с 10:00 до 20:00.
Где: ул. Байзакова, 280 (SmArt.Point, зал: Amphitheatre).

Продолжение цикла лекций Алексея Антошевского «Облака для самых маленьких‎»‎

Алексей Антошевский — Senior System Administrator, RHCA, обладатель черного пояса по Linux-администрированию — задает правильный вектор в обучении и эксплуатации облачных инфраструктур.

Часть 2.1 Золотой образ

С чего начинается работа любого сервера? Правильно, с установки операционной системы. Но поскольку мы находимся в облаке, традиционной установки ОС не будет. В облачной среде инстансы разворачиваются на основе готовых или кастомных образов операционных систем. Из этих образов создаются тома (volume), на которых поднимаются инстансы — процесс, известный как image-based provisioning.

Хотя образы одинаковы, у каждого инстанса могут быть свои особенности, и их нужно настроить. Эта задача выполняется с помощью системы cloud-init.

Предварительная настройка инстансов

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

1. Cloud-init определяет, нужно ли запускаться при загрузке.
2. Система настраивает источники метаданных и применяет сетевые настройки.
3. Начинается использование пользовательских данных, происходит настройка дисков и монтирование файловых систем.
4. Выполняются модули cloud-init, которые не влияют на другие этапы загрузки.
5. Устанавливаются пакеты, запускаются SCM-инструменты и пользовательские скрипты.

Способы конфигурирования инстансов

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

Для конфигурации инстансов есть несколько вариантов. Один из них — использование модулей cloud-init. Они позволяют хранить конфигурации в YAML-файлах и охватывают большинство задач по локальной настройке системы. Однако есть и недостатки: сложность отладки и обработки исключений — если важно получить рабочий сервер с первого раза.

Другой вариант — использование кастомных скриптов. Они работают аналогично модулям cloud-init, но также могут быть сложными в поддержке. Третий вариант — внешние инструменты управления, такие как AWX (Ansible Tower), Puppet, Chef и т.д. Они предоставляют большие возможности для обработки исключений и выполнения операций второго дня, но добавляют дополнительную точку отказа.

Создание золотого образа

Вернемся к образам. На прошлой лекции мы уже говорили о дилемме baking vs frying. Мы выберем золотую середину: подготовим образ заранее, но так, чтобы его можно было быстро настроить при развертывании. Для этого можно использовать GitLab CI и автоматизировать сборку «золотого образа».

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

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

Об Ansible-плейбуках, резервном копировании и провиженинге managed-сервиса 1С Алексей рассказал на DevOpsDays — вот полная запись доклада.

Продолжение цикла лекций Алексея Антошевского
«Облака для самых маленьких‎»‎

Алексей Антошевский — Senior System Administrator, RHCA, обладатель черного пояса по Linux-администрированию — задает правильный вектор в обучении и эксплуатации облачных инфраструктур.

Часть 1.2. Cloud native: краткое пособие по скотоводству

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

Ручная настройка

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

Управление конфигурациями (SCM)

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

Инфраструктура как код (IaC)

Использование подхода «инфраструктура как код» отчасти решает эту проблему. Мы декларативно описываем состояние инфраструктуры, а инструменты вроде Terraform или OpenStack Heat приводят систему в это состояние. Но и тут есть свои нюансы. При работе с облаком нет понятия установки операционной системы: инстансы запускаются из образов. Возникает дилемма. Образ, из которого мы запускаем инстанс, можно подготовить заранее — этот процесс называется «выпекание». Альтернатива ему — «прожарка»: взять образ чистой ОС, запустить его и настроить.

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

Иммутабельная инфраструктура: от питомца к стаду

К тому моменту, когда мы научимся описывать инфраструктуру кодом, у нас поменяется подход к серверам. Когда мы знаем, как настроен каждый сервер, когда они ломаются, а мы на них заходим и чиним — мы относимся к ним, как к своим «питомцам». В облаках мы относимся к серверу, как к голове в «стаде скота». И глобально нас волнует только то, каким образом это «стадо» выполняет свою работу, сколько ресурсов оно потребляет. Мы всегда подстраиваем его под состояние, которое нам нужно.

В этом и заключается «cloud native». Начать практику вы можете прямо сейчас, у нас в PS Cloud.

Кроме того, в пятницу Алексей раскроет тему подробнее в докладе «50 оттенков жёлтого: пилим кастомный SaaS на базе OpenStack» на конференции DevOpsDays'24. Все билеты уже распроданы, но вы сможете подключиться онлайн.

⭐️ Спикер #5 на DevOpsDays Almaty'24 — Алексей Антошевский, Senior Linux Engineer, RHCA.

Алексей занимается автоматизацией и участвует в создании облачных услуг в PS Cloud Services.

В своем докладе Алексей расскажет, как устроены сервисы в облаке на примере сервиса для 1С: какой процесс видит пользователь и что происходит со стороны провайдера.

Также Алексей затронет тему синтетических тестов производительности 1С, поговорит о дилемме baked vs fried, о подготовке образа и cloud init, а также о роли AWX (Ansible Tower) в создании сервиса. ✨

👉🏻 Регистрируйтесь на DevOpsDays Almaty’24 и не пропускайте ни одного докладчика — интересного будет много.

#devops #devopsdays #speakers

@devopsdayskz

🥇 Золотой спонсор DevOpsDays Almaty 24 — PS Cloud Services

PS Cloud Services — независимый казахстанский облачный провайдер, размещает оборудование в 7-ми дата-центрах в Алматы, Астане и Ташкенте. За 20 лет работы на рынке стал партнером значительной части Казнета.

Предоставляет сервисы на базе собственной облачной платформы PS Cloud, услуги SOC/ОЦИБ, все виды веб-хостинга, лицензии на ПО.

🤝 Такое партнерство поможет объединить опыт и знания, а также обменяться передовыми практиками и идеями — всё это послужит на благо казахстанскому DevOps-сообществу.

👉🏻 Регистрируйтесь на DevOpsDays Almaty’24 и будьте готовы к мощному контенту, полезным знакомствам и крутому нетворкингу — интересного будет много.

#devops #devopsdays #partners

@devopsdayskz

Друзья, нам исполнился 21 год! И пролетевший год был очень продуктивным.

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

В шести дата-центрах Казахстана и Узбекистана, а также в облачной платформе PS Cloud, мы создали условия для соответствия требованиям международного стандарта безопасности индустрии платежных карт PCI DSS 3.2.1. и получили соответствующие сертификаты. Несколько крупных финансовых организаций, разместив у нас инфраструктуру, выполнили до половины требований стандарта, значительно сэкономили на сертификации и снизили риск утечки данных своих клиентов.

Мы стали серебряным партнером Linux Foundation, Cloud Native Computing Foundation и сертифицированным провайдером услуг Kubernetes (KCSP). Таким образом, наши специалисты в очередной раз подтвердили свою экспертизу в администрировании Kubernetes и сопровождении клиентских проектов.

Еще мы запустили услуги в пятом дата-центре в Алматы и соединили все дата-центры в городе собственным оптоволокном, запустили сервис защиты от DDoS-атак, тестируем новую услугу аренды облачных серверов для 1С. И это — только крупные вехи минувшего года.

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

PS Cloud Services — сертифицированный провайдер услуг Kubernetes

Что общего между Боинг, Нетфликс, университетом Принстон, ИКЕА, Эфириум, БиБиСи и правительством Его Величества Карла III? Эти и сотни других организаций состоят в Linux Foundation (LF), консорциуме, который поддерживает разработку и распространение открытого ПО.

Членство в консорциуме можно получить, обладая большими деньгами или глубокой экспертизой. Фонд Cloud Native Computing Foundation (CNCF), одно из направлений деятельности LF, занимается поддержкой облачных технологий, включая Kubernetes, и сертифицирует лучших облачных провайдеров по всему миру.

Теперь мы в их числе. PS Cloud Services — серебряный партнер Linux Foundation и CNCF, сертифицированный провайдер услуг Kubernetes (KCSP). Мы гордимся новой победой и рады поделиться ею с вами.

Если вы разрабатываете cloud native приложения, обращайтесь за консультацией к нашим экспертам. Команда Certified Kubernetes Administrator поможет минимизировать операционные риски, повысить производительность вашей инфраструктуры и оптимизировать процессы DevOps.

Облачный вебинар в Узбекистане

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

Завтра, 27 июня в 15:00, мы расскажем:

— что такое облака, и как они помогают бизнесу расти;
— почему облака — это следующее поколение хостинга;
— для какого бизнеса подходят облака;
— как сократить капитальные расходы на хостинг IT-инфраструктуры.

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

Регистрация на вебинар по ссылке.

Мы сертифицировали все ЦОДы и облако по PCI DSS

С гордостью сообщаем, что мы завершили процесс сертификации всех дата-центров Казахстана и Узбекистана по стандарту PCI DSS 3.2.1. Теперь этому стандарту соответствует большинство наших услуг: размещение и аренда серверов, вся облачная платформа PS Cloud — IaaS, K8saaS, DBaaS, LBaaS — облачные VPS, объектное хранилище и Virtuozzo Application Platform.

Для справки: PCI DSS, «Payment Card Industry Data Security Standard», учрежден международными платежными системами (VISA, MasterCard и прочими) для защиты данных платежных карт. Его соблюдение обязательно для компаний, которые обрабатывают, хранят или передают данные карт, по условиям международных платежных систем (Visa, MasterCard и другие). Клиенты компаний, соответствующих PCI DSS, могут безопасно проводить транзакции и значительно снизить риск утечки платежных данных.

Получение сертификации включает детальный аудит более 600 контрольных пунктов по всем аспектам безопасности данных: защищенности сетей, управления уязвимостями, контроля физического и сетевого доступа, шифрования данных, поддержки политики ИБ, мониторинга и тестирования. Размещая IT-инфраструктуру у нас, в зависимости от выбранного типа хостинга, вы автоматически выполняете до половины требований PCI DSS. Ниже вкратце описаны наши зоны ответственности.

Ограничение физического доступа к данным

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

Установка и поддержка межсетевого экрана

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

Изменение параметров по умолчанию

Учетные записи, системные пароли и прочие параметры ПО, заданные производителем по умолчанию, легко доступны для злоумышленников. Поэтому мы меняем все дефолтные параметры и устраняем известные уязвимости до установки подсистем в дата-центры.

Антивирусная защита

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

Контроль доступа к сетевым ресурсам и данным

Система автоматически генерирует журналы событий и позволяет отслеживать подозрительную активность пользователей. Регистрируются все действия пользователя с неограниченными правами (root) и административными привилегиями, а также создание и удаление объектов системного уровня. Журналы событий безопасности проверяются ежедневно.

Тестирование систем безопасности

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

Кроме того мы разделяем с клиентом еще несколько зон ответственности: безопасное хранение данных, шифрование данных при передаче через общедоступные сети, аспекты разработки безопасных приложений, идентификацию пользователей и соблюдение политик ИБ. Подробности вы сможете узнать при обращении в отдел продаж: [email protected].

Как устроена тарификация PAYG в PS Cloud?

PAYG — («Pay-As-You-Go», оплата по мере потребления) — общепринятая для облачных сервисов модель тарификации. PAYG аналогична оплате электроэнергии по счетчику. Клиент оплачивает только те ресурсы, которые он использовал, без расходов на резервирование оборудования. В итоге клиент получает выгодное персонифицированное предложение, а провайдер — оптимизацию мощностей.

Облачная платформа PS Cloud — это совокупность сервисов «Облачные серверы», «Облачные базы данных», «Балансировщики нагрузки» и «Кластеры Kubernetes». Для клиента все эти сервисы — набор базовых ресурсов: ядра процессора, оперативная память, диски и IP-адреса. Характеристики и сочетания ресурсов могут отличаться, но суть всегда одна и та же:

PS Cloud = CPU + RAM + DISK + IP

Из этого набора ресурсов клиент может конструировать IT-инфраструктуру любой конфигурации:

1 CPU + 1 RAM + 1 DISK + 1 IP

Добавлять ресурсы, когда появляется необходимость:

2 CPU + 2 RAM + 2 DISK + 2 IP

Отключать лишние ресурсы, когда потребность в них исчезает:

1 CPU + 2 RAM + 1 DISK + 2 IP

В ряде случаев используется пятый ресурс — виртуальная машина или экземпляр (INSTANCE). По сути, это все те же 4 ресурса, объединенные в неразборную конструкцию.

INSTANCE = (CPU + RAM + DISK + IP)

Масштабирование экземпляров возможно только целиком. До масштабирования:

1 INSTANCE = 1 (CPU + RAM + DISK + IP)

После масштабирования:

2 INSTANCE = 2 (CPU + RAM + DISK + IP)

На странице сервиса «Облачные серверы» есть калькулятор цен, в котором можно прогнозировать потребление ресурсов. Точная сумма формируется ежечасно по факту потребления и отражается в разделе «Расходы» консоли управления облачным проектом.

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

(продолжение)

3. Распределенные сетевые атаки.

‣ Fan-in (many IPs to one IP). Множество источников атакует и перегружает одну цель.
‣ Fan-out (one IP to many IPs). Один источник направляет трафик на множество целей для разведки уязвимостей или создания отвлекающего маневра
‣ Swarms (many IPs to many IPs). Скоординированная атака множества источников по множеству целей для создания массового хаоса.
‣ Multiple targets attacks. Как скоординированные, так и непоследовательные атаки по различным целям, направленные на манипуляцию защитными ресурсами.

4. Атаки разной продолжительности и интенсивности.

‣ Long persistent attacks. Продолжительные атаки, создающие постоянную нагрузку на цель.
‣ Pulsed attack. Чередование активной фазы атаки с периодами покоя.
‣ Slow evolving attacks. Атаки с постепенным нарастанием интенсивности, что делает их менее заметными для систем мониторинга на ранней стадии.
‣ Low-rate attacks (from 1000 pps/10 Gbps). Атаки с низкой скоростью отправки пакетов, маскирующиеся под легитимный трафик.

Сервис «DDoS Secure» блокирует все эти атаки, автоматически адаптируясь к их методам в течение 25 секунд после обнаружения.