В нашей компании завершилась акция, проходившая с 18 октября по 18 ноября 2018 года среди пользователей новой услуги Cloud2.

В результате розыгрыша, проведённого 20 ноября, победителем и владельцем NVMe SSD ускорителя нового поколения Intel Optane 900p 480GB стал Башкирцев Матвей Николаевич!

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

Сегодня мы публикуем список участников розыгрыша NVMe SSD ускорителя Intel Optane 900p 480GB среди пользователей Cloud2!
В соответствии с правилами, в розыгрыше участвуют только те аккаунты, расходы по которым в период с 18 октября по 18 ноября суммарно составили от 1100 рублей.
Мы специально не публикуем ФИО участников и их email, чтобы избежать непреднамеренного распространения ваших персональных данных.
Вместо этого идентификатором участника в розыгрыше будет являться код услуги Cloud 2, который вы всегда можете посмотреть в списке своих услуг в биллинге, например:


Список кодов услуг, участвующих в розыгрыше*:
12671
12687
14003
14010
14327
14391
14398
14604
14644
14713
14754
14761
14765
14768
14842
14893
Если вы считаете, что вы попадаете под участие в розыгрыше согласно условиям акции, но вашей услуги нет в списке участников, напишите нам на support@netpoin-dc.com

Проведение розыгрыша
Розыгрыш будет проведён 20 ноября 2018 года в 11:00 по томскому времени путём случайного выбора публичным генератором randstuff числа из представленного выше списка.
Трансляция розыгрыша будет доступна на www.youtube.com/watch?v=VotiVs98-wU

Спасибо за внимание и удачи нашим участникам!

Уважаемые абоненты, в рамках продолжения цикла улучшений услуги Cloud2 мы увеличили частоту vCPU для экземпляров LowCPU в 2 раза. Теперь частота ядра составляет 2 GHz, ранее была 1 GHz. Это означает, что машины LowCPU теперь будут работать в два раза быстрее.

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

Мы по-прежнему не рекомендуем машины LowCPU для нагруженных проектов, позиционируя их как решения для малых серверов специальных нужд — DNS, VPN, Proxy, FTP, балансировщик Nginx и т.п. Для сервисов, которым требуется высокая производительность и низкая задержка обработки выбирайте только машины HighCPU или Ultra (скоро будут доступны).

Спасибо за то, что вы выбираете наши услуги.
billing.netpoint-dc.com/billmgr?func=register&lang=ru

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



Виртуальная машина состоит из следующих компонентов, которые перечислены далее:

• Ядра vCPU — виртуальный процессор VM;
• RAM — область оперативной памяти VM, которая выделена ей в использование;
• контроллер Watchdog I6300ESB;
• ROOT-диск — первый диск виртуальной машины;
• DATA-диски — опциональные диски, которые могут быть добавлены к виртуальой машине;
• NIC0 — управляемая сетевая карта, настройки которой выделяются по DHCP;
• NIC1-N — дополнительные неуправляемые сетевые карты, которые не отображаются в интерефейсе панели и используются для создания дополнительных частных сетей.

Разберем все компоненты по-отдельности.

Ядра vCPU
Данный параметр определяет вычислительные возможности виртуальной машины. В зависимости от типа машины выделяются различные ядра и выполняются различные соотношения между физическими ядрами (включая Hyper-Threading) и виртуальными ядрами:

• Lowcpu — соотношение виртуальных и физических ядер для вычислительного узла — 1:3. Таким образом, на одно физическое ядро может выделяться до 3х виртуальных, что определяет потенциально более низкую производительность CPU. Частота ядра виртуального процессора от 1.00 до 3.00 GHz. Данный тип машин не рекомендуется для задач, когда требуется гарантировать производительность операций, поскольку в определенные моменты доступная частота может значительно упасть из-за перегрузки CPU.
• Highcpu — соотношение виртуальных и физических ядер для вычислительного узла — 1:1-1.5. На одно физическое ядро выделяется от одного до полутора виртуальных ядер. На практике можно считать, что соотношение 1 к 1. Таким образом, в случае Highcpu вы можете рассчитывать на полную производительность физических ядер, выделенную монопольно для вашей виртуальной машины. Частота ядра виртуального процессора от 2.90 до 3.80 GHz, что делает этот тип машин подходящими для сервисов, которым требуется высочайшая производительность ядер, например, для использования с приложениями, от которых ожидается стабильный отклик с минимальной задержкой.
• Ultra — соотношение ядер 1:1. Частота ядер от 2.90 до 3.80 GHz. В этом типе машин виртуальной машины всегда доступны все ресурсы нижележащего CPU. Обычно, производительность CPU VM Ultra соответствует CPU Highcpu, однако, в крайних случаях Ultra может быть несколько быстрее.

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



Можно видеть, что процессор загружен не более чем на 22% (зеленая область представляет собой свободные ресурсы). Данный узел уже выделен на 60% по памяти. Таким образом, процессор не является узким местом. Это изображение отражает картину утилизации CPU, характерную для всех узлов Highcpu и показывает, что вы можете рассчитывать на доступность всех ядер в полном объеме.

RAM
В Cloud2 используется гипервизор KVM, каждой машине выделяется заказанный объем RAM, который монопольно используется машиной по своему усмотрению.

ROOT-диск
Первый диск виртуальной машины. Данный диск используется для размещения операционной системы. Его размер может увеличиваться пользователем при необходимости. Производительность ROOT-диска определяется характеристиками, которые заданы для сервисного предложения. Например, для машины highcpu.2c4g определены следующие характеристики доступа к ROOT-диску:

• Read IOPS: 2000
• Write IOPS: 1000
• Read MBS: 160
• Write MBS: 80

Таким образом, независимо от размере ROOT-диска виртуальная машина highcpu.2c4g будет обладать вышеуказанными характеристиками доступа к ROOT-диску. Если указанной производительности недостаточно, необходимо сменить сервисное предложение на большее, например, highcpu.4c8g:

• Read IOPS: 4000
• Write IOPS: 2000
• Read MBS: 200
• Write MBS: 100

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

NIC0
Первая сетевая карта управляется системой CloudStack. Данная сетевая карта автоматически получает сетевые настройки по DHCP. Так же, для данной сетевой карты Cloud2 поддерживает группы безопасности, которые используются в качестве внешнего шлюза безопасности виртуальной машины и позволяют ограничить нежелательный трафик.

NIC1
Вторая сетевая карта связывает все машины одного аккаунта в приватную сеть на скорости 10Gbit/s, что позволяет реализовать самые требовательные к скорости передачи данных задачи. Данная сеть является неуправляемой и настраивается пользователем по своему усмотрению.

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

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

billing.netpoint-dc.com

Уважаемые пользователи, для машин LowCPU, HighCPU произведены улучшения, которые значительно увеличили производительность дискового доступа. В ходе улучшения скорость доступа на чтение в IOPS и MBs была увеличена в два раза.

Для применения изменений достаточно остановить и снова включить виртуальную машину.

Использование watchdog I6300ESB в виртуальных машинах в Cloud2
Сегодня мы расскажем о полезной возможности Cloud2, которая позволяет повысить доступность виртуальных машин за счет использования виртуального устройства watchdog, которое доступно внутри VPS.

Сначала несколько слов о том, что такое watchdog. В апаратных серверах промышленного класса всегда есть специальная микросхема, которая работает автономно от всего и представляет собой обычный таймер с действием при достижении нуля. По умолчанию, таймер отключен и действие не установлено, но с помощью специального программного обеспечения, например, ipmitool, можно это изменить и задать определенное поведение — например, перезапуск сервера через reset при достижении нулевого значения, а начальное значение, например, установить в 360 секунд. Далее, в системе запускается специальная программа, которая просто обновляет таймер, не давая ему достигнуть нулевой отметки. Таким образом, пока система работает и процессы выполняются, таймер обновляется и watchdog не срабатывает, однако, как только операционная система зависла, программа, обновляющая таймер перестает работать тоже. В течение максимум 360 секунд счетчик достигнет нулевой отметки, и система перезагрузится с помощью виртуального нажатия на кнопку «reset». Механизм абсолютно надежный, поскольку работает на уровне аппаратного обеспечения, позволяя администраторам в большинстве случаев значительно уменьшить время недоступности систем при возникновении ошибочных ситуаций.

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

Реализация в Cloud2. В Cloud2 используется гипервизор KVM, который поддерживает watchdog на базе микросхемы Intel i6300esb, эмуляция которой и осуществляется гипервизором. Мы задали действие для watchdog как reset, таким образом при зависании машина будет перезапускаться.

Использование watchdog в Cloud2. Использование i6300ESB в ОС Linux не представляет труда. Для начала использования необходимо выполнить следующие действия (Ubuntu Linux 16.04):

Установить ПО watchdog:

# apt-get update && apt install watchdog

Узнать как собрана поддержка устройства I6300ESB для вашей ОС:

# grep I6300ESB /boot/config-$(uname -r)
CONFIG_I6300ESB_WDT=m

Если «m», значит, модуль необходимо загрузить. Если «y», значит, что поддержка встроена в ядро, если «n», требуется пересборка ядра. Скорее всего, у вас будет «m», если это так, необходимо установить дополнительные компоненты ядра:

# apt install linux-image-extra-$(uname -r)

Теперь можно загрузить модуль:

# modprobe i6300esb
# lsmod | grep i6300esb
i6300esb 16384 1

Видим, что все отлично — модуль загружен. Теперь необходимо добавить его для автоматической загрузки. Пакет watchdog в Ubuntu позволяет сделать это через добавление параметра в настройки запуска сервиса watchdog:

# cat /etc/default/watchdog 
run_watchdog=1
run_wd_keepalive=1
watchdog_module="i6300esb"

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

watchdog-device = /dev/watchdog

в файле /etc/watchdog.conf.

Выполним запуск сервиса watchdog:

# service watchdog start

Если запуск прошел успешно, то в журнале /var/log/syslog, Вы увидите следующие записи:

Oct 2 03:55:08 sop watchdog[22526]: test=none(0) repair=none(0) alive=/dev/watchdog heartbeat=none to=root no_act=no force=no
Oct 2 03:55:08 sop watchdog[22526]: watchdog now set to 60 seconds
Oct 2 03:55:08 sop watchdog[22526]: hardware watchdog identity: i6300ESB timer

Если система зависнет, то в течение 60 секунд для нее будет выполнено действие «reset». Убедитесь, что сервис watchdog корректно стартует после перезапуска системы.

Проверить работоспособность можно посредством генерации состояния Kernel Panic:

echo c > /proc/sysrq-trigger

Не более чем через 60 секунд система должна перезагрузиться.

В статье приведена настройка только для Ubuntu Linux. Для Debian, CentOS и других ОС семейства Linux настройка будет похожа. Настройка для других операционных систем (MS Windows, *BSD и других) осуществляется посредством интерфейсов и приложений, которые в них предоставляются для взаимодействия с таймером i6300esb и в этой статье не рассматриваются.

Case Study об использовании подсистемы Linux FS-Cache для решения проблемы производительности хранилища


У одного из наших клиентов большой портал, данные которого хранятся на отдельном выделенном NFS сервере. На сегодняшний день — это множество изображений, которые хранятся в одном плоском каталоге и занимают более 3 TB. Даже листинг этого каталога занимает несколько десятков секунд. До недавнего времени все работало более-менее неплохо, но потом движок обновили и случилось чудо, нагрузка на хранилище выросла на порядок. Все наши увещевания, что было хорошо, стало плохо ни к чему не привели, разработчики просто разводят руками.

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

Новый виток боли начался недавно — у клиента стало заканчиваться место в хранилище, мы выполнили перенос на временный сервер, но проблема усугубилась — после перемонтирования хранилища NFS IOPS-ы стали зашкаливать, так как сервер приложений выкачивал все данные непосредственно с хранилища, и система просто встала колом. К счастью, на сервере приложений было около 500 GB высокоскоростного пространства на SSD и мы решили попробовать использовать FS-Cache для решения проблемы. Это был первый опыт применения данной технологии, но делать было нечего, все равно ничего не работало.

Проверяем совместимость ядра

# grep CONFIG_NFS_FSCACHE /boot/config-3.13.0-147-generic
CONFIG_NFS_FSCACHE=y

Отлично, ядро пересобирать не надо.

Монтируем NFS с нужным параметром FSC

server://files /mnt/vgslow-data nfs nfsvers=4,async,rw,_netdev,fsc 0 0

Обращаем внимание. Перемонтирование через remount не даст эффекта. Необходимо отмонтировать и смонтировать с параметром «fsc».

Устанавливаем и настраиваем демон кэширования

apt-get install cachefilesd
Редактируем настройки
# cat /etc/cachefilesd.conf 
###############################################################################
#
# Copyright © 2006,2010 Red Hat, Inc. All Rights Reserved.
# Written by David Howells (dhowells@redhat.com)
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version
# 2 of the License, or (at your option) any later version.
#
###############################################################################

dir /var/cache/fscache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

# Assuming you're using SELinux with the default security policy included in
# this package
# secctx system_u:system_r:cachefiles_kernel_t:s0

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

Указываем, что демон должен запускаться:

# cat /etc/default/cac
cacerts cachefilesd 
root@np0121:~# cat /etc/default/cachefilesd 
# Defaults for cachefilesd initscript
# sourced by /etc/init.d/cachefilesd

# You must uncomment the run=yes line below for cachefilesd to start.
# Before doing so, please read /usr/share/doc/cachefilesd/howto.txt.gz as
# extended user attributes need to be enabled on the cache filesystem.
RUN=yes

# Additional options that are passed to the Daemon.
DAEMON_OPTS=""

Запускаем сервис

service cachefilesd start

Проверяем работоспособность

# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV  FSID             FSC
v4 b078194a 801  0:35 16f9381700e59eda yes

Важно, чтобы в колонке FSC было yes. Это означает, что кэширование активировалось.

Теперь смотрим статистику кэша:

# cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=6 dat=1890275 spc=0
Objects: alc=1097490 nal=0 avl=1097490 ded=1016804
ChkAux : non=0 ok=171729 upd=0 obs=0
Pages : mrk=148687337 unc=145492607
Acquire: n=1890281 nul=0 noc=0 ok=1890281 nbf=0 oom=0
Lookups: n=1097490 neg=925761 pos=171729 crt=925761 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=1759445 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=2393196 ok=465345 wt=723800 nod=1927851 nbf=0 int=0 oom=0
Retrvls: ops=2393196 owt=662915 abt=0
Stores : n=118288880 ok=118288880 agn=0 nbf=0 oom=0
Stores : ops=2049040 run=120337487 pgs=118288447 rxd=118288880 olm=0
VmScan : nos=145461870 gon=0 bsy=0 can=433 wt=11
Ops : pend=662994 run=4442236 enq=153450538 can=0 rej=0
Ops : dfr=36586 rel=4442236 gc=36586
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

Если счетчики двигаются, значит все ОК, настройка завершена.

Заключение
Нам повезло, что нагрузка клиента в основном представляет собой операции чтения, что позволяет использовать FS-Cache совместно с NFS. Если бы проблема была в нагрузке по записи, мы бы не смогли эффективно воспользоваться данной технологией.

billing.netpoint-dc.com/billmgr?func=register&lang=ru

Настройка сетевой карты VM
Первое, что необходимо сделать перед переносом — убедиться в том, что виртуальная машина настроена на получение сети по DHCP с первой сетевой карты. Если вы используете Linux и в настройках сетевой карты или настройках Udev есть MAC-адрес, удалите его:

В CentOS редактируем файлы, указываем, что получение адреса происходит по DHCP, удаляем HWADDR:

/etc/sysconfig/network-scripts/ifcfg-*
/etc/udev/rules.d/70-persistent-net.rules # удаляем

В Ubuntu/Debian делаем то же самое редактированием следующих файлов:

/etc/network/interfaces
/etc/network/interfaces.d
/etc/netplan/*.yaml
/etc/udev/rules.d/70-persistent-net.rules # удаляем

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

Конвертация образа VM в формат QCOW2
Сконвертировать образ в формат QCOW2 можно с помощью утилиты qemu-img, которая входит в поставку Qemu. К примеру для VMDK:

qemu-img convert -f vmdk -O qcow2 vm.1-disk1.vmdk vm-disk1.qcow2

Сконвертированный образ можно сжать в BZ2 или GZip для ускорения загрузки:

bzip2 vm-disk1.qcow2

Получите файл vm-disk1.qcow2.bz2.

Выбор способа загрузки образа в облако
Мы рекомендуем загрузку через URL, но CloudStack позволяет осуществить и локальную загрузку.

Вы не можете загрузить в Cloud2 файл размером более 200 GB. Если необходимо загрузить большой образ, обратитесь в техническую поддержку и мы выполним загрузку через системные механизмы.

Рассмотрим как организована процедура загрузки образа. Когда вы загружаете образ, неважно, с помощью URL или c локального компьютера, CloudStack сначала загружает образ в хранилище, а потом выполняет его проверку и, если необходимо, извлечение из архива. Это может занять много времени. Вы не сможете использовать образ, пока он не будет полностью подготовлен.

Если вы планируете осуществить импорт образа в Cloud2 с минимальными затратами времени, а образ VM занимает много места, вы никогда ранее это не делали, в наличии нет утилиты конвертации Qemu-img, обратитесь в техническую поддержку и мы сделаем это за вас.

Если вы решили загружать образ с помощью URL, то вам необходимо разместить его на сервере, который доступен по порту 80, 8080, 443. Мы рекомендуем использовать Nginx или Apache. Мы НЕ рекомендуем использовать IIS.

При загрузке с URL никогда не используйте WEB-сервисы для хранения файлов (Google Drive, Yandex Диск, Dropbox, …), обычно они не отдают совместимый с загрузчиком CloudStack HTTP-поток, а ориентированы на браузеры и выполняют различные переадресации. Если вам недоступен обычный HTTP-сервер без ограничений, выбирайте локальную загрузку.

Не используйте HTTPS с самоподписными сертификатами. Используйте HTTPS только в том случае, если на сервере установлен корректный SSL сертификат.

Загрузка через скачивание с URL
Итак, убедитесь, что вам доступен образ для скачивания, через браузер. Для примера будем использовать образ, хранящийся на DL.OPENVM.EU:

http://dl.openvm.eu/cloudstack/macchinina/x86_64/macchinina-kvm.qcow2.bz2

Скачайте его из браузера и убедитесь, что загрузка началась. Если все работает, можно прервать загрузку. Обратите внимание. Образ имеет расширение qcow2 и сжат с помощью bz2. Образы для гипервизора KVM должны иметь формат Qcow2. Теперь можно начать загрузку образа в Cloud2. Для этого зайдите в панель управления, перейдите в раздел Templates и нажмите на кнопку «+ Add» в правой верхней части экрана. Вы увидите диалоговое окно следующего вида:


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

• URL — источник загрузки, в нашем примере dl.openvm.eu/cloudstack/macchinina/x86_64/macchinina-kvm.qcow2.bz2
• Name — имя шаблона;
• Description — описание шаблона;
• Zone — зона, в которую будет загружен шаблон, сейчас мы предоставляем услуги только в зоне Tomsk;
• Hypervisor — KVM, другие гипервизоры в Cloud2 не поддерживаются;
• Original XS Version is 6.1+ — не используется с гипервизором KVM, включать не нужно;
• Root Disk Controller — рекомендуется выбирать VirtIO SCSI, VirtIO или osdefault;
• Format — устанавливаем QCOW2; для MS Windows лучше устанавливать как osdefault;
• OS Type — выбирайте максимально приближенный формат к вашей операционной системе, если нет точного или вы его не знаете;
• Extractable — указывайте, если хотите, чтобы шаблон можно было скачать;
• Password Enabled — указывайте, если в шаблоне используется Cloud Init или другой механизм установки внешнего пароля и SSH-ключа;
• Dynamically Scalable — для KVM неприменимо;
• Public — установите, если хотите чтобы другие пользователи видели ваш шаблон (обычно не нужно устанавливать);
• HVM — указывает, что используется аппаратное ускорение.

Если все указали правильно — нажимайте «OK». Теперь будем смотреть прогресс загрузки. Шаблон из примера очень маленький — 50 MB, на его загрузку уйдет меньше минуты. В реальности шаблоны могут загружаться очень долго.

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

Итак, смотрим как загружается шаблон. Для этого кликнем на шаблон и перейдем на вкладку Zones:


Как видно, шаблон загрузился на 23% и его статус Ready = No. Если нажимать кнопку «Refresh», через несколько секунд статус изменится:

Если шаблон большой и сжат BZIP2, его распаковка займет много времени, шаблон будет загружен на 100%, но не готов: Ready = No. Вы должны дождаться, пока статус готовности станет равным «Yes».

Теперь шаблон готов к использованию.

Загрузка с локального компьютера
Загрузка с локального компьютера выполняется точно так же, как и загрузка с URL, для ее осуществления необходимо нажать кнопку «Upload From Local», выбрать файл на локальном диске и указать все параметры, как и в случае загрузки с URL.


После этого начнется загрузка и будет продолжаться пока файл не будет отправлен на сервер. Если вы будете смотреть статус загрузки, то увидите загадочное состояние «Not Uploaded» вместо процентов. Это нормально для данного способа загрузки, продолжайте периодически обновлять состояния до изменения статуса «Download Complete» и «Ready».

Удаление шаблонаУдаление шаблона производится из конкретной зоны. Для этого перейдите в эту зону на вкладке Zones и удалите шаблон из нее:


billing.netpoint-dc.com/billmgr?func=register&lang=ru

Установлены пиринговые отношение с сетью Hurricane Electric (HE) в режиме тестовой эксплуатации. HE — крупнейший оператор хостинга и датацентров, признный лидер по надежности оказания услуг во всем мире. Мы надеемся, что связность с HE позволит нашим абонентам получать еще более качественные услуги.

Подключение организовано на площадке MSK-IX в Москве.

Для продвижения нашей новой услуги Cloud2 мы решили устроить розыгрыш SSD-ускорителя Intel Optane 900P размером 480 GB. Память 3d-Xpoint совершила революцию в мире SSD, предоставляя недостижимую для других SSD производительность и надежность. Мы в НетПоинт широко используем продукты Intel, основанные на 3d-Xpoint и наши клиенты уже успели оценить их по достоинству.

Сегодня мы объявляем розыгрыш такого ускорителя среди пользователей Cloud2.


В настоящее время все карты Intel Optane идут в комплекте с бесплатным эксклюзивным кораблем для игры Star Citizen — Sabre Raven.

Для участия в розыгрыше необходимо заказать услугу Premium VPS с ресурсами не менее 4 GB RAM и 60 GB дискового пространства (1100 рублей). В этой квоте можно создать от 1 до 4х VPS, например, высокопроизводительный VPS: highcpu.2c4g с диском 60 GB или 4 lowcpu.1c1g.

Розыгрыш состоится 20 ноября 2018 года среди пользователей, которые потратили за период с 18 октября по 18 ноября не менее 1100 рублей на услуги Cloud2. Розыгрыш будет осуществляться случайным выбором из всех счетов в биллинге, которые удовлетворяют указанным выше критериям. Номера всех счетов, участвующих в розыгрыше, будут опубликованы на сайте НетПоинт.

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

Все аккаунты, которые уже используют Cloud2 и соответствуют критериям, описанным выше участвуют в розыгрыше.

Отказ от ответственности. В том случае, если компания Intel перестанет распространять ускорители с купоном на Sabre Raven, мы будем разыгрывать ускоритель без этого корабля. Однако, в настоящий момент, нам не известно о таких планах поставщика.

billing.netpoint-dc.com/billmgr?func=register&lang=ru