company_banner

Новая панель управления облачными серверами

  • Из RSS
Новая панель управления облачными серверами
Новости одним абзацем:
  • обновили панель управления;
  • исправили нумерацию дисков;
  • добавили кнопку для отправки багов веб-интерфейса, которая умеет делать “скриншоты” веб-страницы;
  • улучшили графики;
  • шаблоны Arch linux.


Теперь обо всём подробнее:

Интерфейс


В качестве основы для интерфейса теперь используется бутстрап. Спасибо твиттеру за это.


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


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


Новый интерфейс управления облачными серверами Селектел

Запрет на удаление машин расширили на другие операции, которые могут привести к даунтайму:


new_interface6

Нумерация дисков


Наконец-таки исправили. До определённого момента у нас номер диска выставлялся равным номеру виртуальной машины. Если дисков было два, или диск отключался и подключался к другой машине, то… Короче, ничего хорошего. Теперь всё просто – каждый следующий диск получает номер +1 от предыдущего.


Новый интерфейс управления дисками облачных серверов Селектел



Отзывы


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


Обратите внимание: на картинке подсвечен один блок и затенён другой (что позволяет отправлять скриншот, замазав приватные данные или другую информацию “not for disclose”.


Интерфейс отправки сообщений об ошибках в панели управления облачными серверами Селектел

Потребление


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


Для объяснения причины этого нужно посмотреть, как у нас организован аккаунтинг виртуальных машин:


Каждый объект, составляющий виртуальную машину, обсчитывается независимо. Некоторые (например, диски), вообще отдельными сервисами. Виртуальная машина состоит из следующих компонент: VM, VDI (диск), VBD (блочное устройство), VIF (сетевое устройство). Каждый из этих компонентов имеет несколько ресурсов, за использование которых взимается плата по мере расходования этих ресурсов.


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

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


Когда пользователь смотрит на общее списание по аккаунту, он видит сумму списаний по всем принадлежащим (или принадлежавших) ему компонент.


Однако, когда человек открывает вкладку “потребление” у виртуальной машины”, то перед нами возникает задача: а какие компоненты относятся к виртуальной машине? Для now(), то есть для текущего состояния машины задача проста: что подключено, то и относится.


А для машины в прошлом месяце, к которой когда-то были подключены диски, а теперь их нет? До определённого момента мы эту проблему игнорировали и показывали списания в прошлом для компонент, из которых машина состоит “сейчас”.


Таким образом, если от машины отключали диск (удаляли VBD), то глядя на потребление машины в прошлом, мы видели на этом месте нули. Не очень очевидно, да.


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


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


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


Ну и последнее изменение – мы решили сделать нормальную навигацию в прошлом. Идею адаптировали из cacti: можно задать интервал с какого по какое время смотреть, можно листать вперёд/назад и задавать шаг листания.


Новый интерфейс потребления облачных серверов Селектел

Графики


Мы реализовали не только суммирование по удалённым объектам, но и аналогичное “суммирование” для графиков, то есть после отключения диска его статистика по-прежнему доступна. Более того, раз мы сделали суммирование, то теперь у нас есть агрегированные графики по IO для нескольких дисков сразу.


Ну и, заодно, мы реализовали возможность показывать несколько графиков одновременно.


Новый интерфейс графиков потребления ресурсов облачных серверов Селектел

Arch Linux


Мы добавили поддержку Arch Linux. И 32 и 64 бита. Я не уверен, можно ли его считать серверным дистрибутивом, и применимо ли к нему понятие stable. Используйте на свой страх и риск.

Selectel
95,26
ИТ-инфраструктура для бизнеса
Поделиться публикацией

Комментарии 28

    –1
    Весь пост на главную?!
      +1
      Да, некрасиво получилось.
      +1
      Со старой панелью можно было жить, а вот API не хватает.
        +1
        До конца января будет. Сейчас программисты хотят не сделать плохо и перепроверяют всю логичность, стройность названий и т.д.
          0
          ec2tools будут поддерживацца?
            0
            С большой вероятностью нет, потому что у нас разная модель устройства и организации VM. На уровне start/stop постараемся сымитировать, более тонкие процессы точно нет.
              0
              Ок.

              А вот еще вопрос: планируется разделение прав по серверам?

              Положим, я хочу в одни тулзы положить один auth токен для одного проекта (пусть создает и рулит своими серверами, и только), а в другие тулзы — другой токен. Вобщем, по аналогии с хранилищем.
                0
                Я думал, скорее, о токенах «per server», то есть токен, с которого возможны только операции с заданной VM (или даже подмножество операций).

                Группировки серверов я не планирую.
                  0
                  Тут вот какая штука — хотелось бы уметь из тулзов создавать новые сервера и полностью их настраивать. Это подразумевает операцию «создать сервер» в админке облака (сейчас руками). Как бы сделать так, чтобы можно было и это скриптом делать?.. Положим, хочу, запаковать все развертывание в jenkins job или что-то подобное, по одной кнопке чтоб.

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

                  А дальше так: я права на этот job даю разработчикам и одминам этого проекта — и они спокойно рулят своими серверами на общем аккаунте компании.

                  А > 1 сервера на проект — это более чем частотный случай, взять хотя бы dev/prod.
                    +1
                    Создание сервера, разумеется, будет. Совместимости с амазоном я при этом не могу обещать — потому что lifecycle сервера у нас и у амазона сильно различаются.

                    Относительно лимтированных по операции токенов — обсуждаемо. В далёком тумане такое есть, но за пределами более-менее сформулированного roadmap'а.

                    Предлагаю вернуться к этому вопросу сразу после публикации информации про API, тогда мы будем думать о его дальнейшем развитии, и постараемся учесть все предложения.
                      0
                      Как раз потому пишу, что логичность и стройность ведь сейчас закладываете :)

                      Фик с ним с амазоном, тащемта, лишь бы shell-обвязка была, навроде supload.

                      Насчет лимитированных операций — я опишу use case со своей точки зрения.

                      1. Компания с одним аккаунтом на Selectel занимается разработкой и хостингом многих веб-проектов.
                      2. Каждый проект включает в себя 1-2 постоянно включенных сервера (типа, 24/7 продакшен + в рабочее время общий dev) плюс что-нибудь вроде ночной сборки, которая включает в себя создание и уничтожение сервера или их набора.
                      3. Для каждого проекта сервера создаются и конфигурируются полностью автоматически, т.е. ваше API — наше все. Все это заворачивается в скрипты, джобы, права на которые раздаются внутри компании, ручная работа минимальна. Как раз недавно в этом ключе писали про Jenkins.

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

                      1. Создавать сервера (доступные по умолчанию только для этого подаккаунта), с ограничением, что не более N серверов всего может быть активно на подаккаунт (чтобы создавалка не зациклилась ночью).
                      2. Управлять своими серверами (вкл, reset).
                      3. Деструктивные операции (жесткий poweroff, удаление) — по умолчанию можно. Но, если из джоба создали продакшн, то потом для конкретного инстанса хочется руками из из админки запретить деструктивные операции, чтобы его потом другой джоб не мог снести даже по ошибке.

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

                      Как-то так. Спасибо, что дочитали. Публикуйте API, посмотрим конкретнее :)
        +2
        Сделали красиво. Вот вы панель сделали на bootstrap а графики на чём у вас находятся если не секрет?
          0
          Хранятся в нашей собственной разработке (я о ней как-то писал), рисуется dygraphs (http://dygraphs.com/)
          +2
          Спасибо!
            0
            > Мы добавили поддержку Arch Linux. И 32 и 64 бита.

            Спасибо.
              0
              С учётом, что я его на дух не перевариваю (так же как и systemd), то даже «пожалуйста» сказать не могу. :(
                0
                systemd не так плох как кажется на первый взгляд. С некоторых сторон даже удобнее чем sysvinit, но не будем тут холивор в очередной раз разводить.

                А так — было всего две или три реальных подлянки, которые ломали систему, всё остальное — кривые руки.
                  0
                  Главная проблема systemd: если он ломается, то всё. Совсем всё. Если сейчас что-то в init.d ломается, я это могу починить.

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

                    > У меня органическая неприязнь к userspace-приложениям, которые пытаются из себя операционные системы изображать.

                    Ви таки не любите emacs? :)
                      0
                      Кстати, да. И emacs я тоже… не то, чтобы не люблю, не использую. Впрочем, редакторы это отдельный разговор.

                      Каждый раз, когда кто-то в userspace решает, что он умнее операционной системы, получается в лучшем случае «но оно всё-таки работает», а в худшем «ну его нафиг».
              +1
              А что-ж не рассказали, что вводите абонплату за IP? ;-)
              Мой VPS у вас теперь в 1.5 раза дороже стал ;-)
                +1
                Причем в качестве беслпатного аналога предлагают ipv6, который еще не работает и когда заработает — неизвестно. Печально :( По сути просто удорожают стоимость услуги.
                  +2
                  Именно для того, чтобы не удорожать, я тут сейчас и устраиваю аврал по IPv6. Он, кстати, работает уже. Правда, в интерфейсе пока не реализовано. Пишите тикет, выдадим.

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

                  Причина — 35% виртуальных машин лежит выключенными и жрёт IP. А мы уже свою последнюю /22 получили и больше получить не можем. Это очень большое количество адресов, и если часть клиентов откажется от IP (а мы предоставим эту возможность), то мы сможем на IPv4 протянуть чуть подольше.
                    0
                    Так сделайте как на амазоне — пусть платят за IP если его не используют.
                      0
                      Я попробую успеть с 17 сделать динамические IP. С большой вероятностью не успею (потому что хочется не тяп-ляп, а нормально), но я точно в этом направлении работаю.
                        0
                        Это чтобы можно было из админки явно переназначать с одной машины на другую? Это круто, и для продакшена незаменимо.
                          0
                          Насчёт «переназначать» это отдельный вопрос (основные все танцы вокруг того, что разные сети в разные виланы смотрят), речь о другом: чтобы машина получала себе новый (или тот же, что и раньше, но без гарантии) адрес при включении и отдавала при выключении.

                          Это решит проблему «лежит и IP не юзает, хотя и занимает», это же открывает несколько интересных моментов.

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

                Самое читаемое