VMmanager Вопросы
  • Дата создания
    10 июля 2017
  • Топиков
    24
  • Ограничение на постинг
    0.000
  • Категория:
    Панели

Миграция с CentOS Linux 7 для платформ DCImanager, VMmanager и BILLmanager

Миграция с ОС CentOS 7 на AlmaLinux 8 для VMmanager
Вам предстоит выполнить ряд действий:

Подготовка
Проверьте совместимость оборудования с ОС AlmaLinux 8, загрузив ОС AlmaLinux в режиме Live Media.
Перенесите виртуальные машины на другой узел кластера при смене ОС на узле кластера. (См. статью «Миграция виртуальных машин» для более подробной информации).
Создайте резервную копию платформы на внешнем хранилище. (Смотри статью «Резервное копирование платформы»).
Смена ОС
Подключитесь к серверу по SSH.
Установите последнее доступное обновление ПО: yum update -y
Перезагрузите сервер: reboot
Установите ПО Elevate:
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
Установите фреймворк Leapp:
yum install -y leapp-upgrade leapp-data-almalinux
Проверьте готовность системы к смене ОС:
leapp preupgrade
Изучите вывод команды и файл отчёта /var/log/leapp/leapp-report.txt для информации о возможных проблемах при смене ОС.
Настройте фреймворк Leapp:
rmmod pata_acpi
leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Запустите смену ОС:
leapp upgrade

Перезагрузите сервер:
reboot
Проверьте версию ОС:
cat /etc/os-release

Действия после смены ОС на узле кластера
Подключитесь к узлу кластера по SSH.
Удалите старые репозитории:
rm /etc/yum.repos.d/ispsystem-base6.repo
rm /etc/yum.repos.d/CentOS-QEMU-EV.repo


На сервере с платформой измените настройки файрвола:
docker exec -it vm_box bash
cd /opt/ispsystem/vm
/usr/bin/ansible-playbook -i <NODE IP>:22, -e targets=all -e ansible_python_interpreter='auto_silent' -e datacenter_type='common' -e ssh_port='22' -e network_autosetup_enabled='1' -e is_lxd='0' -e dc_ips='' -e dc_ips6='' -e closed_contour='0' etc/playbooks/node/firewall.yml --timeout 60 -b

Готово! По завершении этих шагов ваша платформа будет успешно мигрирована на поддерживаемую ОС AlmaLinux 8, обеспечив стабильную и безопасную работу системы.

Миграция на ОС AlmaLinux 8 без переустановки DCImanager 6
Миграция операционной системы (ОС) представляет собой важный процесс, требующий внимательности и последовательности действий для обеспечения бесперебойной работы платформы. В случае смены операционной системы с CentOS 7 на AlmaLinux 8 без переустановки DCImanager 6, есть особенности и шаги, которые не предусмотрены разработчиками ОС CentOS. Поэтому процедура миграции может привести к неудачному результату, а платформа будет недоступна в процессе смены ОС на сервере с платформой.

Чтобы успешно выполнить миграцию, необходимо следовать инструкциям для обеспечения безопасной и бесперебойной работы платформы. Вот пошаговая инструкция для миграции с ОС CentOS 7 на ОС AlmaLinux 8 с помощью ПО Elevate:

Проверьте совместимость оборудования с ОС AlmaLinux 8. Вы можете загрузить ОС AlmaLinux 8 в режиме Live Media для проведения данной проверки.
Подключитесь к серверу по SSH и сделайте резервную копию платформы для предотвращения потенциальных неполадок во время миграции:
dci backup
Резервная копия будет сохранена в директории /opt/ispsystem/dci/backup/. Сохраните копию на внешнем носителе.
Установите последние доступные обновления ПО и перезагрузите сервер:
yum update -y
reboot
Установите ПО Elevate и фреймворк Leapp:
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux
Проверьте готовность системы к смене ОС:
leapp preupgrade
Изучите вывод команды и файл отчёта /var/log/leapp/leapp-report.txt для выявления возможных проблем при смене ОС.
Настройте фреймворк Leapp и запустите смену ОС:
rmmod pata_acpi
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
leapp upgrade
Перезагрузите сервер и проверьте версию ОС:
reboot
cat /etc/os-release

Миграция через резервное копирование DCImanager 6
В случае миграции с ОС CentOS 7 на любую поддерживаемую ОС, необходимо следовать определенной последовательности действий. Пошаговая инструкция для миграции через резервное копирование DCImanager 6 представлена ниже:

Создайте новое значение токена для вашей лицензии в личном кабинете на my.ispsystem.com или обратившись в техническую поддержку.
Создайте резервную копию платформы:
dci backup
Копия будет сохранена в директории /opt/ispsystem/dci/backup/. Если помимо платформы на сервере находится локация, создайте резервную копию директории /opt/ispsystem/dci/os_templates/. Сохраните резервные копии на внешнем носителе.
Если помимо платформы на сервере находится локация, остановите платформу:
dci down
Установите поддерживаемую ОС и подключитесь к серверу через SSH.
Если в системе не установлен архиватор tar или утилита curl, установите их через соответствующие команды для используемой ОС.
Скачайте установщик и сделайте файл установщика исполняемым:
curl -O https://download.ispsystem.com/6/dci/dcibox/dci
chmod +x dci
Создайте директорию /opt/ispsystem/license/ и скопируйте ранее созданную резервную копию платформы в директорию /opt/ispsystem/dci/backup/.
Запустите восстановление платформы из резервной копии:
./dci restore -b=<backup_file>
Активируйте лицензию в интерфейсе DCImanager 6 и выполните дополнительные шаги, если на сервере находится локация.
Обновите базу данных:
docker exec -it mysql bash -c "mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD"
Успешное выполнение этих шагов обеспечит безопасную и бесперебойную миграцию вашей платформы на новую ОС.

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

Важно убедиться, что версия BILLmanager на новом сервере не ниже, чем на старом. Миграция возможна между серверами с разными операционными системами.

Подготовка:
  • Подготовьте новый сервер, установите на него BILLmanager, активируйте триальную лицензию через личный кабинет ISPsystem.
  • Включите режим технического обслуживания на старом сервере на время переноса.
  • Импортируйте данные пользователей со старого сервера на новый.
  • Перенесите кастомные XML-файлы, дополнения и плагины на новый сервер. Это можно осуществить с помощью команд scp.
  • Перенесите настройки витрины со старого сервера на новый, скопировав соответствующие директории.
  • Установите отсутствующие пакеты ПО, такие как обработчики услуг, платежные системы и почтовые шлюзы, на новом сервере.
  • Привяжите лицензию BILLmanager к новому серверу, активируя коммерческую лицензию через личный кабинет.
  • Отключите режим технического обслуживания на старом сервере после успешного переноса.
  • После завершения переноса рекомендуется отключить или удалить BILLmanager со старого сервера, чтобы избежать конфликтов из-за одинаковых настроек обработчиков услуг.

Подготовка нового сервера включает установку BILLmanager, активацию триальной лицензии через личный кабинет ISPsystem и вход в BILLmanager через браузер для активации лицензии.

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

Инструкция по переносу BILLmanager на новый сервер:
Шаг 1: Включение режима технического обслуживания
«Режим технического обслуживания» временно останавливает работу модулей обработки и почтовых шлюзов в BILLmanager. Чтобы включить его на старом сервере, создайте пустой файл /usr/local/mgr5/etc/billmgr.DoNothing.

Шаг 2: Импорт данных
На старом сервере:
Создайте резервную копию с веб-интерфейса BILLmanager, перейдя в раздел Инструменты → Резервное копирование и нажав кнопку «Запустить». Сохраните архив с резервной копией.
Сохраните настройки брендирования.
Скопируйте директории на новый сервер с помощью команд scp
scp /usr/local/mgr5/skins/dragon/local_* root@:/usr/local/mgr5/skins/dragon/
scp /usr/local/mgr5/etc/brand_settings.billmgr.xml root@:/usr/local/mgr5/etc/

На новом сервере:
Перейдите в раздел Инструменты → Резервное копирование → кнопка Закачать, выберите архив с резервной копией с предыдущего сервера и нажмите «Восстановить».
После восстановления из резервной копии на новом сервере в конфигурационном файле может быть указан IP-адрес старого сервера. Укажите IP-адрес нового сервера в конфигурационном файле ihttpd /usr/local/mgr5/etc/ihttpd.conf. Перезапустите BILLmanager:
/usr/local/mgr5/sbin/mgrctl -m billmgr exit

Шаг 3: Перенос кастомных XML-файлов, дополнений и плагинов
Если у вас есть кастомные XML-файлы, дополнения и плагины, выполните следующее:
Создайте на новом сервере директорию /usr/local/mgr5/backup/, если такой директории еще нет.
Перенесите существующие кастомные файлы с помощью команд scp
scp -r /usr/local/mgr5/etc/xml/ root@:/usr/local/mgr5/backup/
scp -r /usr/local/mgr5/addon/ root@:/usr/local/mgr5/backup/
scp -r /usr/local/mgr5/src/ root@:/usr/local/mgr5/backup/

Скопируйте содержимое директорий с помощью команд:
cp -n /usr/local/mgr5/backup/xml/* /usr/local/mgr5/etc/xml/
cp -n /usr/local/mgr5/backup/addon/* /usr/local/mgr5/addon/
cp -n /usr/local/mgr5/backup/src/* /usr/local/mgr5/src/ 

Шаг 4: Перенос файлов витрины
Для переноса витрины со старого сервера на новый, скопируйте на новый сервер следующие директории:
# /usr/local/mgr5/skins/showroom/ — файлы витрины провайдера;
scp -r /usr/local/mgr5/skins/showroom/ root@<IP-адрес_нового_сервера>:/usr/local/mgr5/skins/showroom/
# /usr/local/mgr5/etc/showroom.sample.dragon/ — файлы шаблонов, на основе которых создаются витрины.
scp -r /usr/local/mgr5/etc/showroom.sample.dragon/ root@:/usr/local/mgr5/etc/showroom.sample.dragon/

Шаг 5: Установка отсутствующих пакетов
После переноса базы данных, на новом сервере запустите установку всех отсутствующих пакетов обработчиков услуг, платежных систем и почтовых шлюзов. Для этого выполните команду:
/usr/local/mgr5/sbin/mgrctl -m billmgr fix.modules

Шаг 6: Привязка коммерческой лицензии к новому серверу
После переноса BILLmanager на новый сервер, зайдите в личный кабинет, где заказана лицензия. Удалите триальную лицензию из личного кабинета. В настройках коммерческой лицензии введите IP-адрес нового сервера. Обновите файл лицензии, нажав на кнопку «Обновить лицензию» в веб-интерфейсе BILLmanager, либо загрузив лицензию вручную с помощью команды:
/usr/local/mgr5/sbin/licctl fetch billmgr

Шаг 7: Отключение режима технического обслуживания
Чтобы отключить режим технического обслуживания, удалите файл /usr/local/mgr5/etc/billmgr.DoNothing

Также мы планируем в этом году обеспечить поддержку ОС Alma Linux 9 для продуктов DCImanager и VMmanager, однако обращаем ваше внимание, что инструмент миграции Leapp для OC CentOS 7 предполагают разделения процесса миграции: сначала с OC Centos 7 на AlmaLinux 8, и только с нее уже на AlmaLinux 9.

Слетает лицензия после обновления

Выполните, пожалуйста, следующие команды на сервере платформы:
curl -O https://nextcloud.ispsystem.net/index.php/s/msdm8P3pog7rfzc/download/license.gz
gunzip license.gz
chmod +x /root/license && docker cp /root/license vm_license_1:/opt/ispsystem/license/bin/license && docker restart vm_license_1
Если токен изменился воспользуйтесь следующей документацией:
Подключитесь к серверу с VMmanager по SSH с правами суперпользователя (по умолчанию root).
Перейдите в директорию с файлами лицензий:
cd /opt/ispsystem/license

Удалите из директории все файлы, кроме machine_id:
shopt -s extglob
rm -v !("machine_id")

В интерфейсе VMmanager перейдите в → Обзор системы.
В поле Ключ лицензии введите
docs.ispsystem.ru/vmmanager-admin/o-platforme/litsenzirovanie

Как сделать root

Входим на сервер через пользователя. Например у нас это логины centos, debian, ubuntu тд
Далее входим в root через команду:
sudo su root

Правим конфиг ssh:
nano /etc/ssh/sshd_config

А именно строчку:
#PermitRootLogin prohibit-password

Меняем на:
PermitRootLogin yes

И обязательно задаем пароль для root пользователя:
passwd root

Потом перезагружаем сервер и готово. Обычный вход через root.

Миграция с ОС CentOS 8 на AlmaLinux 8

Чтобы выполнить миграцию:
Подключитесь к серверу по SSH.
Проверьте версию ОС:
cat /etc/redhat-release
Если версия ОС ниже 8.5, измените пути к репозиториям:
sed -i -r 's|^(mirrorlist.+)$|#\1|g; s|^#baseurl=http://mirror.centos.org/\$contentdir/\$releasever/|baseurl=https://vault.centos.org/8.5.2111/|g' /etc/yum.repos.d/CentOS-*.repo
Установите последние обновления ПО:
sudo yum update -y
Скачайте скрипт миграции:
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
Остановите платформу:
vm stop
Запустите скрипт:
sudo bash almalinux-deploy.sh
Сообщение при успешном выполнении скрипта
Migration to AlmaLinux is completed

Если запуск скрипта завершился с ошибкой вида
Пример ошибки
Verify almalinux-release-latest.rpm package ERROR
/root/.alma.X46iDx/almalinux-release-latest.rpm: digests SIGNATURES NOT OK
импортируйте GPG-ключ репозитория AlmaLinux вручную и перезапустите скрипт:
sudo rpm --import https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux && sudo bash almalinux-deploy.sh
Проверьте, что AlmaLinux установлен:
cat /etc/redhat-release
Пример ответа
AlmaLinux release 8.5 (Arctic Sphynx)

Проверьте, что по умолчанию загружается ядро AlmaLinux:
sudo grubby --info DEFAULT | grep AlmaLinux
Пример ответа
title=«AlmaLinux (4.18.0-348.el8.x86_64) 8.5 (Arctic Sphynx)»

Запустите платформу:
vm start

Как импортировать ВМ в VMmanager?

Вы можете импортировать виртуальную машину (ВМ), созданную с помощью технологии виртуализации QEMU-KVM, в платформу VMmanager. Импорт возможен только для ВМ с одним диском.

Если импортируемая ВМ сохранена в формате RAW, её надо предварительно конвертировать в формат Qcow2.

Если диск импортируемой ВМ находится в Ceph, создайте в VMmanager хранилище Ceph и подключите его к кластеру.

На импортированных ВМ вы не сможете:
  • изменить пароль средствами VMmanager;
  • автоматически добавлять и удалять IP-адреса;
  • автоматически изменить раздел диска.
Чтобы импортировать ВМ:
На сервере с VMmanager:
Если нужно импортировать ВМ без изменения IP-адреса
Авторизуйтесь в VMmanager с правами администратора:
curl -X POST 'https://domain.com/auth/v3/auth' -d '{"email": "admin_email", "password": "admin_pass"}'
В ответ придёт сообщение вида:
{
"expires_at":"2020-03-30 10:24:21",
"id":2,
"session":"544EA22F56A1416A8A1CEFD0"
}
Сохраните из полученного ответа значение параметра session — id сессии.

Выполните команду для создания ВМ:
curl -k -H 'Cookie: ses6=<session>' -H 'isp-box-instance: true' -H 'x-xsrf-token: <session>' -X POST  "https://domain.com/vm/v3/host" -d '{"name":"<vm_name>", "cluster":<cluster_id>, "storage":<storage_id>, "account":<user_id>, "domain": "vm.example.com", "os": <os_id>, "password":"<vm_password>", "ram_mib":<ram_value>, "hdd_mib": <disk_value>, "cpu_number":<cpu_quantity>, "ip_addr": {"name": "<ip_address>", "ip_pool":<pool_id>, "ip_network": <network_id>}}'
пример
curl -k -H 'Cookie: ses6=6258704D423C0F26E862B' -H 'isp-box-instance: true' -H 'x-xsrf-token: 6258704D423C0F26E862B' -X POST  "https://vm6.domain.com/vm/v3/host" -d '{"name":"test-solus", "cluster":1, "account":3, "domain": "test-solus.example.com", "os": 24, "password":"qwerty", "ram_mib":512, "hdd_mib": 20480, "cpu_number":1, "ip_addr": {"name": "172.31.214.42", "ip_pool":1, "ip_network": 2}}'
Остановите созданную ВМ: Виртуальные машины → выберите ВМ → меню → Остановить → Остановить.

Если IP-адрес импортируемой ВМ будет изменён
Создайте ВМ с необходимыми параметрами: Виртуальные машины → Создать VM. В поле Операционная система выберите NoOS. Если вам нужно перенести ВМ с диском в Ceph, выберите хранилище Ceph.
Остановите созданную ВМ: Виртуальные машины → выберите ВМ → меню → Остановить → Остановить.

На сервере с импортируемой ВМ:
Выключите ВМ.

Подготовьте диск ВМ:
Если ВМ находится в LVM-хранилище или сохранена в формате RAW

Конвертируйте диск ВМ в формат Qcow2:
qemu-img convert -f raw -O qcow2 path_to_vm/vm_raw vm_qcow
Пояснения к команде
path_to_vm/vm_raw — путь и имя исходного файла ВМ в формате RAW
vm_qcow — имя выходного файла в формате Qcow2
Скопируйте диск ВМ в формате Qcow2 на узел кластера VMmanager.

Если диск ВМ находится в Ceph
Подключитесь к серверу-монитору Ceph с исходной ВМ и экспортируйте её диск:
rbd export pool-1/vm_disk /tmp/vm_output.raw
Пояснения к команде
pool-1 — имя пула Сeph
vm_disk — имя диска ВМ
/tmp/vm_output.raw — путь и имя файла для экспорта в формате RAW
Перенесите диск ВМ на сервер-монитор Ceph, используемый VMmanager.

Импортируйте ВМ в VMmanager:
Если в кластере используется файловое хранилище
Скопируйте файл ВМ в директорию хранения на узле кластера:
cp vm_qcow /vm/<vm_id>_<vm_name>
Пояснения к команде
/vm — директория хранения ВМ
<vm_id>_<vm_name> — имя файла ВМ, содержащее id и имя ВМ. Например, для ВМ с id 12 и именем test-solus имя файла должно быть 12_test-solus.

Если в кластере используется LVM-хранилище
Конвертируйте файл ВМ в формат RAW и скопируйте в LVM-хранилище:
qemu-img convert -f qcow2 -O raw vm_qcow /dev/mapper/<vm_id>_<vm_name>
Пояснения к команде
/dev/mapper/ — путь к LVM-диску
<vm_id>_<vm_name> — имя файла ВМ, содержащее id и имя ВМ. Например, для ВМ с id 12 и именем test-solus имя файла должно быть 12_test-solus.

Если в кластере используется Ceph
На сервере-мониторе Ceph, используемом VMmanager:
Удалите диск созданной ВМ:
rbd rm pool-1/1234_vm_name
Пояснения к команде
pool-1 — имя пула Сeph, используемого платформой
1234_vm_name — имя диска ВМ

Импортируйте диск исходной ВМ:
rbd import vm_output.raw pool-1/1234_vm_name
Пояснения к команде
vm_output.raw — имя файла исходной ВМ
pool-1 — имя пула Сeph, используемого платформой
1234_vm_name — имя диска ВМ

Запустите импортированную ВМ: Виртуальные машины → выберите ВМ → меню → Запустить → Запустить.
Если требуется, подключитесь к ВМ через VNC и измените её сетевые настройки.

Почему мы не покупаем серверы в fiord.ru под VMmanager ?

Продолжаю цикл статей — отвечая на вопросы «почему мы, как клиент, не покупаем серверы».
Мне один знакомый сказал — так это проблема в том, что ты не осилил.
А что, «не осилил» разве не является причиной почему клиент не смог купить услугу?
Как раз таки это и есть причина. Почему клиент выбирает OVH/Hetzner где все работает нормально. А другие ДЦ не покупает, потому что там нихуя не настраивается.

Итак, как-то чел купил там сервер.


Во первых — там ОС ставят по 5 часов, ВРУЧНУЮ.
Целый день убили просто на 3 попытки настроить VMmanager 6

Ему выдали 2 доп IP
5.252.195.142
5.252.195.243

Разумеется сначала я попробовал как ОВХ-Хетзнер где штучные.
Внес в список.

Но не сработало. Узел установился нормально и работал. ВМ создавались — но IP не работали.

А значит видимо нужно гемориться как с selectel допустим или как вот тут.
vm.center/2021/04/qa-vmmanager/ne-dobavlyaetsya-ip-shtuchnyy-v-seti-puly.html
vm.center/2021/04/qa-vmmanager/pochemu-my-ne-pokupaem-servery-v-selectel-pod-vmmanager-.html

Попытка №2
Делаю пулл этот.
И добавляю туда в список всего 2 штуки эти
5.252.195.142
5.252.195.243

Как они написали в тикете
5.252.195.0/24 — 255.255.255.0 — 5.252.195.1
Значит


Но с такими параметрами узел постоянно пишет ошибку.


Итого, на следующий день, т.к. я не дождался пока ДЦ ВРУЧНУЮ переустановит ОС и ушел спать.

Попытка №3


Судя по всему человек до 7 утра дрочил, пока я спал.
И ушел спать только утром. А если бы в VMmanager была настройка как для OVH/Hetzner мы бы уже покупали тачки у fiord и продавали клиентам. Или если бы fiord написал публичное FAQ пошаговое. Но нет, они не клиенто-ориентированы.

Короче, для меня этот ДЦ не пригоден.
Я как клиент не хочу тратить свое время.
И пойду покупать Hetzner/OVH
Все.
Это ответ на вопрос «почему я не покупаю».

Не добавляется IP штучный в "сети-пулы"

Вопрос:
Дата-центр выдал штучные IP адреса, но через «маршрутизацию ОВХ-хетзнер» они не работают. А если попытаться добавить в «сеть-пулл» то пишет ошибку.




Ответ:
Нужно создать сеть от балды. Например /23
А потом внутри пулла указать нужные IP адреса.



Не добавляется узел ошибка hostname

Вопрос:
Не добавляется узел, пишет ошибку такое хостнейм уже существует.
Such a hostname is already used for another node in the cluster


Ответ:
Нужно пойти и изменить хостнейм
Делается это командой
hostnamectl set-hostname New_HostName
например
hostnamectl set-hostname 9900kn7

Почему мы не покупаем серверы в крупных известных ДЦ под VMmanager ?

Вопрос
Почему мы не покупаем серверы в крупных известных ДЦ под VMmanager?

Ответ
Действительно. Почему? Конечно же хочется купить сервер в лучшем дата-центре страны.

Что у нас на слуху такое «надежное и качественное»?
Конечно же ДатаПро
Идем на их сайт и не видим даже формы регистрации не говоря уж о прайс листе
datapro.ru/contacts

Кто еще?
Конечно же модный ixcellerate какой-то там новострой с кучей инвестиций.
Идем на их официальный сайт и что мы там видим? Только форму обратной связи ixcellerate.com/contact-us/ Писать туда себя не уважать.

Кто еще есть в РФ?
Ростелеком конечно же.
rt-dc.ru/services/cloud-vdi/
Или теперь ДатаЛайн тоже — они же.
Идем на сайт www.dtln.ru/uslugi/colocation
Но тоже нет ни прайс листа ничего. Но сайт такой уже хотя бы на прайс лист чуточку похож, уже представление о том, что они умеют складывается. Но — нам не подходит. Мы же за монитором сидим. Писать куда-то — себя не уважать. Я хочу пойти и картой оплатить молча сервер, молча получить в панели, купить молча все дополнения и добавить его в VMmanager и пойти продавать виртуальные машины.

Кто еще в РФ есть?
Были такие 3data.ru вроде запомнились.
Что мы там видим? Хипстерские подорожники. Отличная модель развития.
3data.ru/services/cloud/dedicated
И даже есть возможность купить серверы.
Но там нет современных процессоров. Нельзя сделать услугу лучше чем у других. А иначе какой смысл делать вовсе, чтобы быть хуже других? Нет смысла на старых хеонах что-то вообще запускать.

Кто еще?
Есть еще какой-то, тоже в узких кругах считается надежным ДЦ ru.linxdatacenter.com/ru
ru.linxdatacenter.com/services — но там тоже самое — нас встречает форма обратной связи.

Кто еще в теории может быть в нашей гордой стране?
  • МТС
  • Билайн
  • Мегафон
  • Теле2
Да, что-то у них есть. Но там — облачные решения.

Точно, есть же облачные решения.
Кто это?
Но мы да — хотим сами делать ВМ-ки, сами покупать серверы и делать из них какие-то там ВМ-ки.
А так конечно, был бы я бизнесом, вместо тупой формы обратной связи от ДЦ — я бы пошел в облака.

И как эпилог, прочитайте топик от Октября 2017 года
Изменилось ли что-то на рынке дата-центров ?
  • Я считаю — нет.
  • Дата-центры не хотят себе клиентов.
  • Розничный клиент нашей страны просто унижен и опущен. Он никто. Даже если через него может пройти 20к дедиков или он может накопить 3-5к активных дедика. Даже если он в одиночку поддерживает по 200-300 узлов. И прокачивает 5 миллионов евро оборота за 3-5 лет.

Поэтому короче обычный клиент любой глубинки, не москвы — идет в Яндекс облако. Это самое разумное решение. Или какой-ниб Селектел. Кто-то принципиально сходит в Мейл, потому что там есть отличие и контрактовый подход. Или кто-то настолько ищет нишевое решение что сходит к Крок.
А государство заполняет, обязывает законами, выкупает здания или строит новые на базе РТК.
А нищие вроде нас идут в Европу, где чтобы сделать ВМ-ку, даже админить не нужно уметь. Купил сервер автоматом, выдало за 15 минут, купил сетку на него автоматом, выдало за 5 минут, накатил ОС автоматом, добавил IP, root, password, /29 — 4 поля заполнил в VMmanager — и все, можешь делать ВМ-ки.

Топик написан человеком чисто из интернета. Поэтому мой взгляд именно такой. Вот так типичный интернет задрот видит рынок ДЦ нашей страны.