Новая метрика на StatOnline.ru для хостинг-провайдеров: оценка скорости отклика сайтов

REG.RU представляет новую метрику аналитического сервиса StatOnline.ru. На сайте впервые систематизирован сбор данных о скорости загрузки сайтов клиентов хостинг-провайдеров, работающих в России. Метрика обновляется ежемесячно. Кроме того, дополнена метрика Uptime: появилась информация о времени простоя хостинг-провайдеров.

Среднее суммарное время отклика сайтов, размещённых у хостинг-провайдера, — важный параметр, который влияет на удобство использования интернет-ресурса. Например, отклик в 0,1 сек можно считать идеальным показателем загрузки. Значения от 0,1 до 1 сек считаются приемлемыми. Однако более долгая загрузка страницы приводит к тому, что пользователь теряет ощущение непрерывной и стабильной работы сайта, а поисковые системы не дают такому ресурсу максимальную оценку и пессимизируют в поисковой выдаче. Пределом удержания внимания считается показатель 10 сек.

Новая метрика REG.RU на StatOnline.ru показывает ежемесячную оценку скорости загрузки сайтов, размещённых у российских хостинг-провайдеров. Ранее эта статистика собиралась в виде единичных тестов, в которых чаще всего участвовали один-два сайта, что снижает релевантность подобных исследований. Теперь же полноценный обзор становится доступен как пользователям, так и провайдерам, которые смогут отслеживать свои показатели и улучшать работу услуг и сервисов.

Как формируется метрика
Каждый месяц аналитический сервис составляет список из 20 крупнейших хостинг-провайдеров — они определяются исходя из числа находящихся на обслуживании провайдера доменов в зоне .RU. После этого собираются данные IP-адресов, принадлежащих серверам shared-хостинга каждого провайдера. Затем для всех IP-адресов shared-хостинга создаётся список случайно выбранных сайтов: по два сайта на CMS WordPress, Joomla и «1C-Битрикс» (самые популярные CMS для сайтов в .RU). Для всех ресурсов один раз в 20 минут измеряется время отклика с помощью команды curl %{time_total}. Отчёт составляется исходя из накопленной статистики.

Лидеры декабря
В декабре первое место занял провайдер RU-CENTER с показателем скорости 0,262831 сек. REG.RU расположился в рейтинге на третьем месте — 0,346264 сек. Также в топ-5 оказались провайдеры Hc.ru, «Джино» и «Гарант-Парк-Телеком».


Обновление метрики Uptime
В метрике Uptime появились данные о простое хостинг-провайдеров. В минутах указано среднее время недоступности серверов провайдера за месяц. Основываясь на метрике, пользователи смогут выбирать наиболее надёжных поставщиков услуг для устойчивой работы сайтов и сервисов.
statonline.ru/metrics/hosting_uptime?tld=ru&month=2019-12

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

REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.

Использование FPGA в рабочем процессе гибкой разработки

OVHcloud недавно получил новое имя, чтобы подчеркнуть его направленность: облако, чтобы дать вам возможность легко выполнять свои рабочие нагрузки, не слишком заботясь о базовом оборудовании. Так зачем говорить о ПЛИС?

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


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

Зачем использовать?
ПЛИС являются чрезвычайно общими микросхемами, их можно использовать для построения схем для очень широкого спектра применений:
  • обработка сигналов
  • финансы
  • машинное обучение (классификация)
  • сетей
Их основной интерес заключается в том, что вы не ограничены архитектурой процессора, вы можете создать собственную аппаратную архитектуру, адаптированную к приложению. Обычно это повышает производительность, снижает энергопотребление и снижает задержки.

Для сетевых приложений преимуществами являются:
  • прямое подключение к каналам 100GbE: нет сетевой карты, нет канала PCIe, пакеты принимаются непосредственно на чипе
  • доступ к памяти с чрезвычайно низкой задержкой и очень быстрым произвольным доступом (QDR SRAM: каждый банк обеспечивает около 250 миллионов операций чтения и записи в секунду)
  • возможность строить собственные конвейеры обработки пакетов, максимально использовать ресурсы чипа.
Это позволяет обрабатывать 300 миллионов пакетов в секунду и 400 Гбит / с на одной плате FPGA с энергопотреблением менее 70 Вт.

Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.

Традиционный рабочий процесс разработки FPGA
Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков, все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на микросхеме. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:
// Simple example module: a counter
// Will clear if clear is 1 during one clock cycle.
// Will increment at each clock cycle when enable is 1.
 
`timescale 1ns / 1ps
 
module counter
    #(
        // Number of bits of counter result
        parameter WIDTH = 5
    )
    (
        input                    clk,
 
        // Control
        input                    enable,
        input                    clear,
         
        // Result
        output reg [WIDTH-1:0]   count = '0
    );
 
    always_ff @(posedge clk) begin
        if (clear) begin
            count <= '0;
        end else if (enable) begin
            count <= count + 1;
        end
    end
 
endmodule


Модули можно объединять, соединяя их входы и выходы для создания сложных систем.

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

Симулятор модуля счетчика


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

Базовый симулятор предоставлен Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти симуляторы являются коммерческими и требуют дорогих лицензий.

Сборка двоичного файла
После того, как все тесты пройдены, пришло время получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Второй этап, «место и маршрут», представляет собой очень сложную задачу оптимизации, позволяющую приспособить схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на требуемой частоте. Это может длиться несколько часов, даже до одного дня на очень сложных конструкциях. Этот процесс может завершиться ошибкой, если дизайн слишком ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными значениями, чтобы в конце было больше шансов получить рабочий двоичный файл.

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


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

Используя наше публичное облако
Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:
  • симулятор
  • компилятор Xilinx, Vivado
  • компилятор Intel Quartus

Сервер лицензий для симулятора и компиляторов
Сервер лицензий, а также блоки разработки — это долго работающие экземпляры Public Cloud. Сервер лицензий — это наименьший возможный экземпляр, блок разработки — это экземпляр с быстрым ЦП и большим объемом оперативной памяти. Симулятор и компиляторы установлены на блоке разработки. Полномочия на доступ к серверу лицензий управляются с помощью групп безопасности OpenStack.

Экземпляры, используемые для смоделированных тестов и для компиляции, запускаются с использованием API OpenStack, когда это необходимо. Это очень важно, потому что позволяет параллельно запускать несколько наборов тестов для разных разработчиков. Это также очень важно для компиляции. Мы компилируем наши проекты для нескольких целей (FPGA Stratix V для 10G и FPGA Ultrascale + для 100G), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы выполняем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку в наших проектах задания на сборку могут длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один работающий двоичный файл.

Запуск тестов
Функциональные тесты очень важны, потому что они проверяют каждую функцию, которую предоставляют наши разработки. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать с имитацией дизайна или с реальным дизайном на реальных платах ПЛИС. CDS может автоматически запускать тесты на реальных платах, бронируя лабораторные серверы и подключаясь к ним через SSH. Тот же процесс используется для тестирования производительности.

Результатом этой инфраструктуры является то, что разработчики могут добавить новую функцию в ветку нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Тогда им просто нужно пометить новую версию пакета, чтобы иметь доступ к новой версии. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.

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

HLS
Очень распространенным подходом является использование синтеза высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS возможно развитие на C ++. Также можно использовать OpenCL, который мы тестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы делаем обработку пакетов, наши алгоритмы чрезвычайно просты. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Поэтому мы не смогли эффективно использовать HLS, полученный нами код был на самом деле более сложным, чем та же функция в SystemVerilog.

SystemVerilog чрезвычайно низкоуровневый и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код использовался компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, в настоящее время работающий над проектом с открытым исходным кодом: Chisel.

Chisel — это язык аппаратного дизайна, основанный на Scala. Его основной интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания аппаратного обеспечения. Это также полностью открытый исходный код, что весьма необычно в мире разработки аппаратного обеспечения. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы могли бы избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.

В настоящее время не существует инструментов с открытым исходным кодом для этапа и маршрута, по крайней мере, для самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.

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

Смена парадигмы
Сообщество открытого исходного кода чрезвычайно важно, чтобы продолжать делать разработку ПЛИС все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление бюджетных ПЛИС в проектах FabLabs и хобби-электроники. Мы надеемся, что Xilinx и Intel FPGA последуют этому примеру и что они однажды будут использовать открытые исходные коды для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут стать мощной альтернативой процессорам и графическим процессорам, но чтобы демократизировать их использование в облачных средах, сообщество открытого исходного кода должно стать намного сильнее.

Работа с небольшими файлами с помощью OpenStack Swift (часть 2)

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


Файлы внутри файлов
Мы остановились на простом подходе: мы будем хранить все эти небольшие фрагменты в больших файлах. Это означает, что использование inode в файловой системе намного ниже.


Эти большие файлы, которые мы называем «томами», имеют три важных характеристики:
  • Они посвящены разделу Swift
  • Они только добавляются: никогда не перезаписывают данные
  • Нет одновременных записей: у нас может быть несколько томов на раздел
Нам нужно отслеживать расположение этих фрагментов в объеме. Для этого мы разработали новый компонент: индекс-сервер. Это сохранит каждое местоположение фрагмента: том, в котором он хранится, и его смещение внутри тома.


Для каждого диска существует один индекс-сервер. Это означает, что его домен сбоя совпадает с данными, которые он индексирует. Он связывается с существующим процессом объект-сервер через локальный сокет UNIX.

Использование на LevelDB
Мы выбрали LevelDB для хранения местоположения фрагмента на индексном сервере:
  • Он сортирует данные на диске, что означает, что он эффективен на обычных вращающихся дисках
  • Это экономит место благодаря библиотеке сжатия Snappy

Наши первоначальные тесты были многообещающими: они показали, что нам нужно около 40 байтов для отслеживания фрагмента, по сравнению с 300 байтами, если мы использовали обычную файловую систему хранения. Мы только отслеживаем местоположение фрагмента, в то время как файловая система хранит много информации, которая нам не нужна (пользователь, группа, разрешения ..). Это означает, что значение ключа будет достаточно маленьким для кэширования в памяти, и список файлов будет не требует чтения с физического диска.

При записи объекта обычная быстрая серверная часть создаст файл для хранения данных. С LOSF вместо этого:
  • Получить блокировку файловой системы на томе
  • Добавьте данные объекта в конец тома и вызовите fdatasync ()
  • Зарегистрировать местоположение объекта на индексном сервере (номер тома и смещение внутри тома)
Чтобы прочитать обратно объект:
  • Запросите индекс-сервер, чтобы узнать его местоположение: номер тома и смещение
  • Откройте том и найдите смещение для обработки данных.
Однако нам еще предстоит решить пару проблем!

Удаление объектов
Когда клиент удаляет объект, как мы можем на самом деле удалить данные из томов? Помните, что мы добавляем данные только в том, поэтому мы не можем просто пометить пространство как неиспользуемое в томе и попытаться использовать его позже. Мы используем XFS, и она предлагает интересное решение: возможность «пробить дыру» в файле.

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


Структура каталогов
Индекс-сервер будет хранить имена объектов в плоском пространстве имен, но Swift использует иерархию каталогов.
/mnt/objects/<partition>/<suffix>/<checksum>/<timestamp>.data


Каталог разделов — это раздел, к которому принадлежит объект, а каталог суффиксов — это только три последние буквы контрольной суммы md5. (Это было сделано, чтобы избежать слишком большого количества записей в одном каталоге)

Если вы ранее не использовали Swift, «индекс раздела» объекта указывает, какое устройство в кластере должно хранить объект. Индекс раздела вычисляется путем взятия нескольких битов из пути объекта MD5. Вы можете узнать больше здесь.

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



Перенос данных
Этот новый подход меняет формат на диске. Однако у нас уже было более 50 ПБ данных. Миграция в автономном режиме была невозможна. Мы написали промежуточную, гибридную версию системы. Он всегда будет записывать новые данные, используя новую разметку диска, но для чтения он сначала будет искать на индексном сервере, а если фрагмент не найден, он будет искать этот фрагмент в обычном внутреннем каталоге.

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

Результаты
После завершения миграции активность диска в кластере была намного ниже: мы заметили, что данные сервера индексирования будут помещаться в память, поэтому перечисление объектов в кластере или получение местоположения объекта не потребует ввода-вывода физического диска. Задержка улучшилась как для операций PUT, так и для операций GET, и задачи «реконструкции» кластера могли выполняться намного быстрее. (Реконструктор — это процесс, который восстанавливает данные после сбоя диска в кластере)

Будущая работа
В контексте хранения объектов жесткие диски по-прежнему имеют ценовое преимущество перед твердотельными накопителями. Их емкость продолжает расти, однако производительность на диск не улучшилась. При том же объеме используемого пространства, если вы переключаетесь с дисков объемом 6 ТБ на 12 ТБ, вы фактически вдвое снизили производительность.

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

REG.RU улучшил позиции по new gTLDs среди мировых регистраторов

Динамика регистраций адресов в новых доменных зонах REG.RU заметно опережает не только аналогичные показатели игроков российского доменного рынка, но и многих участников международного. Компания поднялась в рейтинге и теперь, по данным Ntldstats.com, занимает 13 место в мире.

Менее, чем за полгода REG.RU как прямой регистратор увеличил количество зарегистрированных доменных имён в новых зонах с 350 000 до 435 000. Это позволило обойти ранее опережавшего в рейтинге регистратора eNom и подняться на 13 место (другие российские компании не представлены среди топ-30 участников рейтинга).



Завершают топ-15 регистраторы крупных корпораций Alibaba Group Holding Ltd. и Google, занимая 14 и 15 места. Лидер рейтинга ещё один один из проектов Alibaba Group Holding Ltd, а также регистраторы NameCheap и GoGaddy.

Согласно данным ресурса Ntldstats.com, сегодня общее число адресов в new gTLDs достигает почти 32 млн. Из них на российских регистраторов приходится около 600 тыс.

Одновременно с повышением осведомлённости о новых доменных зонах и осознанием их ценности борьба за пользователей между регистраторами будет усиливаться. Клиент будет делать выбор в пользу удобства и развитых экосистем, которые позволяют в одной точке приобрести пул услуг для создания сайта или запуска онлайн-бизнеса. Я уверен, что REG.RU верно развивается в этом направлении, и в перспективе займёт ещё более высокую позицию в мировом рейтинге по показателям new gTLDs
комментирует генеральный директор REG.RU Алексей Королюк

REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.

www.reg.ru

Alipay, WeChat Pay и очень горячая скидка к китайскому новому году



Компания DDoS-Guard поздравляет Вас с Китайским новым годом и дарит скидку 80% на все защищенные VDS. Не упустите возможность заказать быстрые VDS с защитой от DDoS атак и безлимитным CDN для всех размещенных сайтов. Используйте промокод CNY2020DDG при оформлении нового заказа на защищенный VDS до 16.02.2020.
Специальный подарок всем нашим клиентам из Азии: для Вашего удобства мы подключили дополнительные способы оплаты: Alipay, WeChat Pay, UnionPay и другие.

Счастливого нового года!
新年快乐

С уважением, команда DDos-GUARD


https://ddos-guard.net

OVH серверы PL DE UK FR CA US



  • Xeon-E 2274G [4c-8t] (4.9GHz) / 32GB DDR4 ECC 2666MHz / 2x 960 NVMe softraid1 = 7600р/мес
  • Xeon-E 2274G [4c-8t] (4.9GHz) / 32GB DDR4 ECC 2666MHz / 3x 4ТБ HDD softraid1 = 7600р/мес
  • Xeon-E 2274G [4c-8t] (4.9GHz) / 64GB DDR4 ECC 2666MHz / 2x 960 NVMe softraid1 = 8800р/мес
  • Xeon-E 2274G [4c-8t] (4.9GHz) / 64GB DDR4 ECC 2666MHz / 3x 4ТБ HDD softraid1 = 8800р/мес
  • Xeon-E 2288G [8c-16t] (5GHz) / 32GB DDR4 ECC 2666MHz / 2x 960 NVMe softraid1 = 9200р/мес
  • Xeon-E 2288G [8c-16t] (5GHz) / 32GB DDR4 ECC 2666MHz / 3x 4ТБ HDD softraid1 = 9200р/мес
  • Xeon-E 2288G [8c-16t] (5GHz) / 64GB DDR4 ECC 2666MHz / 2x 960 NVMe softraid1 = 10300р/мес
  • Xeon-E 2288G [8c-16t] (5GHz) / 64GB DDR4 ECC 2666MHz / 3x 4ТБ HDD softraid1 = 10300р/мес
  • AMD Epyc 7371 [16c-32t] (3.8GHz) / 128GB DDR4 ECC 2400MHz / 2x 960 NVMe softraid1 = 16800р/мес
  • AMD Epyc 7371 [16c-32t] (3.8GHz) / 128GB DDR4 ECC 2400MHz / 3x 4ТБ HDD softraid1 = 16800р/мес
  • AMD Epyc 7371 [16c-32t] (3.8GHz) / 256GB DDR4 ECC 2400MHz / 2x 960 NVMe softraid1 = 21400р/мес
  • AMD Epyc 7371 [16c-32t] (3.8GHz) / 256GB DDR4 ECC 2400MHz / 3x 4ТБ HDD softraid1 = 21400р/мес
  • 2x Xeon Silver 4214 [24c-48t] (3.2GHz) / 96GB DDR4 ECC 2400MHz / 2x 960 NVMe softraid1 = 17500р/мес
  • 2x Xeon Silver 4214 [24c-48t] (3.2GHz) / 96GB DDR4 ECC 2400MHz / 3x 4ТБ HDD softraid1 = 17500р/мес
  • 2x Xeon Silver 4214 [24c-48t] (3.2GHz) / 192GB DDR4 ECC 2400MHz / 2x 960 NVMe softraid1 = 21800р/мес
  • 2x Xeon Silver 4214 [24c-48t] (3.2GHz) / 192GB DDR4 ECC 2400MHz / 3x 4ТБ HDD softraid1 = 21800р/мес
  • Ryzen 5 3600X [6c-12t] (4.4GHz) / 32GB DDR4 ECC 2666MHz / 2x 500 NVMe softraid1 = 6900р/мес
  • Ryzen 5 3600X [6c-12t] (4.4GHz) / 64GB DDR4 ECC 2666MHz / 2x 500 NVMe softraid1 = 8000р/мес
  • E 2136 [6c-12t] (4.5 GHz) / 32 DDR4 ECC 2666MHz / 2x 500 NVMe softraid1 = 5800р/мес
  • E 2136 [6c-12t] (4.5 GHz) / 32 DDR4 ECC 2666MHz / 2x 4 ТБ SATA softraid1 = 5800р/мес
  • E 2136 [6c-12t] (4.5 GHz) / 64 DDR4 ECC 2666MHz / 2x 500 NVMe softraid1 = 6900р/мес
  • E 2136 [6c-12t] (4.5 GHz) / 64 DDR4 ECC 2666MHz / 2x 4 ТБ SATA softraid1 = 6900р/мес
  • Epyc 7351P [16c-32t] (2.9 GHz) / 128 DDR4 ECC 2400MHz / 2x 500 NVMe softraid1 = 12200р/мес
  • Epyc 7351P [16c-32t] (2.9 GHz) / 128 DDR4 ECC 2400MHz / 2x 4 ТБ SATA softraid1 = 12200р/мес
  • Epyc 7351P [16c-32t] (2.9 GHz) / 256 DDR4 ECC 2400MHz / 2x 500 NVMe softraid1 = 18300р
  • Epyc 7351P [16c-32t] (2.9 GHz) / 256 DDR4 ECC 2400MHz / 2x 4 ТБ SATA softraid1 = 18300р
  • 2x Xeon Gold 5118 [24c-48t] (3.2 GHz) / 96 DDR4 ECC 2400MHz / 2x 500 NVMe softraid1 = 18300р
  • 2x Xeon Gold 5118 [24c-48t] (3.2 GHz) / 96 DDR4 ECC 2400MHz / 2x 4 ТБ SATA softraid1 = 18300р
  • 2x Xeon Gold 5118 [24c-48t] (3.2 GHz) / 192 DDR4 ECC 2400MHz / 2x 500 NVMe softraid1 = 21800р
  • 2x Xeon Gold 5118 [24c-48t] (3.2 GHz) / 192 DDR4 ECC 2400MHz / 2x 4 ТБ SATA softraid1 = 21800р



  • E3-1230v6 [4c-8t] (3.9 GHz) / 16 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 3400р/мес
  • E3-1230v6 [4c-8t] (3.9 GHz) / 16 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 4200р/мес
  • E3-1230v6 [4c-8t] (3.9 GHz) / 32 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 3900р/мес
  • E3-1230v6 [4c-8t] (3.9 GHz) / 32 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 4600р/мес
  • E3-1230v6 [4c-8t] (3.9 GHz) / 64 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 5100р/мес
  • E3-1230v6 [4c-8t] (3.9 GHz) / 64 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 5800р/мес
  • 2x Xeon E5-2630v3 [16c-32t] (3.2 GHz) / 128 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 8800р/мес
  • 2x Xeon E5-2630v3 [16c-32t] (3.2 GHz) / 128 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 9600р/мес
  • E5-1650v4 [6c-12t] (4.0 GHz) / 64 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 5200р/мес
  • E5-1650v4 [6c-12t] (4.0 GHz) / 64 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 6000р/мес
  • E5-1650v4 [6c-12t] (4.0 GHz) / 128 DDR4 ECC 2133MHz / 2x 2TB SATA softraid1 = 7400р/мес
  • E5-1650v4 [6c-12t] (4.0 GHz) / 128 DDR4 ECC 2133MHz / 2x 450 NVMe softraid1 = 8300р/мес

Чтобы заказать напишите тикет тут bill.ovh/billmgr
Франция, Канада, Германия, Великобритания, Польша
Различные дополнения вроде 256 IP сеток (44000р разого за 256 IP)
Или замена дисков.
Или 1 гигабит заменить на 2 или 3.
Все это в тикете.

Виртуальные машины высокой доступности в Cloud2



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

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

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

В связи с наличием потребности в таких «живучих» виртуальных машинах, мы вводим новое семейство высокодоступных машин — HA, тома которых располагаются в GlusterFS. В 2012 году у нас уже был опыт потери данных из распределенной файловой системы Ceph, мы извлекли необходимые уроки и выполняем системное резервное копирование томов GlusterFS, что позволяет восстановить данные виртуальных машин в случае критического сбоя Gluster.


Дисковое пространство тарифицируется по стоимости 10 Руб. в месяц за каждый ГБ данных в томах виртуальной машины.

Сетевые возможности
Каждая машина семейства помимо публичной NIC предоставляет приватную, работающую на скорости 10Gbit/s.

Рекомендации по использованию
Мы не рекомендуем использовать машины HA, если вам требуется высокая прогнозируемая скорость дисковой подсистемы и низкая задержка (например, СУБД с большим количеством операций записи). Если же данное требование не является критичным, возможно использовать данные машины:
  • шлюзы и балансировщики нагрузки;
  • сайты без высокой нагрузки к СУБД на запись, для которых нецелесообразно поднимать вторую реплику;
  • прочие приложения, для которых требуется минимизировать простой до минут без лишних технических средств.
В том случае, если возможно использовать VM Compute, IO или DataBox используйте их. Если же для VM требуется обеспечить работоспособность без привязки к хосту, где она исполняется, обратите внимание на данное семейство.

netpoint-dc.com

Fleio 2020.01



Пользовательский интерфейс операций
С выпуском 2020.01 мы добавили новую функцию пользовательского интерфейса: Операции

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

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

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

Улучшения системы продажи билетов


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

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

Еще одно изменение, которое мы реализовали, — сделать обновления в тикетах более заметными. Чтобы добавить, что мы сделали эти конкретные билеты более смелыми.

Стоит упомянуть изменения и исправления ошибок:
  • Исправлено планирование резервного копирования экземпляров. Разрешить определение дня недели, когда должны создаваться резервные копии, если тип расписания еженедельный.
  • Установите флажок, чтобы разрешить использование настраиваемой текстовой области для добавления настраиваемого кода без изменения при редактировании шаблонов уведомлений
  • Разрешить настройку перенаправления выхода из системы для панелей конечного пользователя и персонала
  • Не разрешать редактирование / удаление ароматов, используемых экземплярами
  • Измените метку ввода имени пользователя для входа обратно на «Имя пользователя» и добавьте настройки внешнего интерфейса, чтобы настроить его.
  • Клиент удален из реселлера после редактирования

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

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

Fleio 2020.01 включает в себя множество других улучшений и исправлений ошибок. Полный список см. В полном списке изменений 2020.01.
fleio.com/docs/changelog/v2020.01.0.html

Ознакомьтесь с последней версией Fleio в онлайн-демонстрации и свяжитесь с нами, чтобы обсудить, как мы можем внедрить Fleio в вашем облаке OpenStack.


fleio.com/
fleio.com/demo

UpCloud получила 18 миллионов евро

  • UPcloud


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

Этот инвестиционный раунд проводился во главе с Connected Capital & Partners, нидерландским инвестором по развитию программного обеспечения для В2В, и в нем приняли участие финская промышленная инвестиция, финская государственная инвестиционная компания, и Inventure, финская венчурная компания, которая также инвестировала в UpCloud в 2016 году.

Вы можете ожидать волнующие новости в течение следующих 24 месяцев! Новое финансирование будет использоваться для расширения групп разработчиков, разработчиков технологий, продаж и маркетинга, а также для дальнейшей разработки новых программных продуктов и функций для вас, наших пользователей. Мы также планируем нанять более 100 новых сотрудников и запустить более 10 новых центров обработки данных на всех наших ключевых рынках в Европе, Азии и Северной Америке, а также на новых рынках, таких как Австралия!

Узнайте больше о новостях финансирования в объявлении и узнайте немного о нашей истории и целях.

Спасибо всем нашим пользователям за ваше постоянное доверие к нам!

Удачного кодирования, Team UpCloud

upcloud.com

Попробуйте наши облачные VDS/VPS



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

У Вас будет выделенный IP, бесплатное администрирование, Канал от 100 мбит/с и никаких ограничений по трафику.

Преимущества:
  • Сверхбыстрые SSD NVMe диски
  • Многоуровневая защита данных
  • Можно изменить параметры сервера в зависимости от потребностей
  • Гарантированные ресурсы
  • Оплата по факту
  • Бесплатный переезд
  • Простое управление
  • Круглосуточная поддержка

Рассчитать стоимость и заказать можно тут: zomro.com/cloud_vds.html