Мало хостеров предлагает тарифы VDS с высокой тактовой частотой процессора, хотя кажется, что всё просто: вставил в сервер i9 помощнее, настроил биллинг и готово.

Когда мы готовили тарифы Hi-CPU, то выяснили, что:

• серверы с i9 потребляют тонны электричества
• поймать баланс и сделать выгодный тариф на качественном железе непросто
• ЦОДы предпочитают с таким не связываться

Рассказываем, как мы справились с этим и запустили Hi CPU.

Зачем нужен Hi-CPU
Мы готовили идеальный тариф под Битрикс. Почему?
Конечно, из-за денег.


По данным CMS iTrack, половина всех сайтов, сделанных на CMS — WordPress и лишь 11,68% сайтов используют Битрикс. Однако по рейтингу CMS Magazine, коммерческих сайтов использующих Битрикс в два раза больше, чем WordPress. Большая часть сайтов на WordPress — блоги, личные сайты и прочие визитки.

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

Так что верным способом стать качественным Битрикс-хостингом было сделать выгодный Hi-CPU тариф и стать featured-partner — попасть в рейтинг рекомендуемых хостеров, который составляет сам Битрикс.

Подготовка: первоначальное тестирование
Для начала мы проверили, сколько Битрикс-попугаев выдает сборка на стандартном тарифе. Процессор — Intel Scalable Xeon Silver 4116. Получили 107 попугаев.


Intel Scalable Xeon Silver 4116 неплохо справляется с типичными VDSовскими задачами, но для Битрикса нужно что-то помощнее, особенно, если цель — попасть на вершину рейтинга.


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

Сначала рассматривали самосбор на основе Intel Core i9-9900K S1151. Некоторые коллеги так и делают и попугаев у них выходит даже больше, чем на серверных процессорах. Однако, как мы упоминали, топовые i9 и сборки на их основе потребляют столько энергии, что пришлось бы либо задрать цену, либо разориться на счетах за электричество. Да и ЦОД был не в восторге: потребовал организовать дополнительное охлаждение стоек и инженеров для настройки и обслуживания самосбора (и дополнительное охлаждение инженеров).

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

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

Оптимальным вариантом показалось найти MicroCloud в 3U. По сути, это 12 серверов в одном, что позволяет в 4 раза экономить место в стойке при той же производительности. Серверы выбирали в ноябре 2018 года и тогда решений в 3U было не так уж много, выбор почти сразу пал на Supermicro SuperServer 5039MS-H12TRF.


Он состоит из двенадцати отдельных нод


Каждая нода это по сути отдельный сервер. У нас другая сборка, чем на картинке, но принцип тот же.

Сердцем выбрали Intel Xeon E3-1270 v6. Опирались на опыт: мы уже использовали этот процессор на платформе Dell R330 для других высоконагруженных проектов. E3-1270 ещё ни разу не подводил, цена и качество нас устраивали.

Для начала купили только один Microcloud: он стоит в районе 20 тысяч долларов, а свободных денег было не так много. Оно и к лучшему: на рынке постоянно появляются новые, более эффективные и недорогие решения. К тому моменту, как появились деньги на новый сервер, мы проанализировали рынок заново.

Первая проблема при установке
Первый MicroCloud доставили через неделю после заказа. Уже в ЦОДе оказалось, что он не помещается в стойку. Мы хотели поставить его к серверам 1U, но направляющие в стойке расположены так, что Microcloud банально не входил. Чтобы его поместить, пришлось бы устроить даунтайм для других серверов и сдвинуть направляющие.

Решили повременить с запуском и поставить Microcloud в новую стойку. Это оказалось оптимальным решением: энергопотребление и тепловыделение у MicroCloud отличается от обычных серверов. Да и сетевое оборудование со своими особенностями.


В MicroCloud планировали установить десяти-гигабитные сетевые карты, чтобы как следует разогнать миграцию VDS-контейнеров. Этот трюк мы уже проделывали с 1U серверами, но с MicroCloud всё оказалось сложнее.

Десяти-гигабитные сетевые карты для MicroCloud серверов оказались большой редкостью. Мы заказывали Low Profile AOM-CTGS-i2TM MicroLP, ждали пару месяцев и получили ответ: «извините, производитель редко сталкивается с подобными заказами. Карты будут готовы через полгода». От идеи пришлось отказаться: пока хватает стандартных гигабитных карт, но в будущем мы ещё раз попытаемся купить десяти-гигабитные.

Настройка шаблона и заявка в Битрикс
Изначально мы собрали шаблон с уклоном на Битрикс, но и удобством для остальных CMS: например, добавили нестандартную для Vesta конфигурацию с выбором версии PHP. Всю конфигурацию и оптимизацию делали на схеме apache + mod_fcgi. Параметры подбирали так, чтобы они давали лучший усреднённый результат для всех тарифов.

Производительность Битрикса зависит напрямую от тактовой частоты процессора. В среднем частота процессоров для тарифов Hi-CPU была на 40-50% больше, чем у процессоров, обслуживающих обычные тарифы. Результаты замеров коррелировали: минимум на 30% больше производительности при высокой нагрузке на сервер, около 60% — в «хорошую погоду».



Когда всё отладили, зарегистрировались на сайте для партнеров Битрикса и заполнили заявку, к которой прикрепили данные с VDS с шаблоном, оптимизированным под Битрикс.

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


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

Цена и здравый смысл
Другие хостинги отправили заявки со своими самыми дешёвыми тарифам, у которых меньше оперативной памяти, места на SSD и трафика, чем у нашего. Мы же послали заявку с более дорогим тарифом, но более подходящим под нормальную работу Битрикса.

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

Создавая VDSina мы делаем ставку на удобство: регистрация должна проходить на лету, без капчи (от у нас неё изжога), проверки паспортных данных и подтверждения номера телефона. Ввёл почту, пополнил баланс на 30 рублей и VDS разворачивается за 60 секунд — для нас это вопрос принципа.

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

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

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

Пока наши клиенты довольны таким раскладом и мы тоже.

Тесты производительности наших Hi CPU



Планы на будущее
Недавно к нам пришёл уже четвертый по счету сервер. На этот раз — Supermicro MicroCloud с 12 x Xeon E-2136, 48 x DDR4 16Gb и 12 x 1TB NVME P4510.


Новый MicroCloud уже ввели в эксплуатацию, и теперь мы строим планы по экспансии Hi-CPU в Нидерланды и другие страны. У нас работают серверы для обычных тарифов в двух нидерландских ЦОДах, но когда встаёт вопрос о чём-то посложнее 1U-сервера, то приходится пройти через 9 кругов согласований.
Но это уже другая история.

https://vdsina.ru

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

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

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

Старая панель была реализована в виде Single Page Application и на этом его хорошие качества заканчивались. После решения очередной головоломки по добавлению кнопки в список, пришло понимание, что нужна альтернатива. Выбор пал на Vue.

Почему SPA?
Single Page Application — идеальный выбор для панели управления. Панель управления в плане рендеринга довольно простая штука, эту работу можно легко доверить браузеру пользователя. К тому же панели не важна SEO-оптимизация, для этого у нас есть основной сайт. Ну и требуемое время на начальную загрузку всех необходимых скриптов пользователи панели воспринимают спокойно в силу специфики самих этих пользователей. Опять же, бекенд у нас получился классическим RestAPI сервисом — для предоставления в будущем открытого API нашим клиентам.

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

Почему Vue?
3 года назад Vue был относительно молодым фреймворком, но уже тогда о нем много говорили и писали, и когда вышел релиз версии 2.0, мы решили сделать ставку на него — и не прогадали. Сначала планировали просто постепенно заменять какие-то компоненты написанные на jQuery и Vue это позволял делать легко. Но потом, после того, как были переписаны довольно объемные компоненты, все таки решили, что лучше переписать вообще все приложение на Vue.
Это бы рискованный шаг и мы решили его сделать по 4 причинам:

• Vue — простой декларативный фреймворк, его понимают даже верстальщики. Если что, под него легко найти разработчика или просто научить товарища. А значит у нас не будет проблем с поиском нового разработчика и его вхождением в проект, если меня переедет трамвай (хвала богам, в моем городе их нет).
• Vue объективно хорош для написания SPA приложений.
• У меня перед глазами был опыт развития React и я предположил, что популярность Vue будет расти так же. Сейчас фреймворк входит в TOP-3 популярных JS-фреймворков (это легко проверить поисковым запросом), уступая только React и Angular. У него хорошая поддержка, развитая экосистема и большое комьюнити.
• Скорость разработки. Лично я сразу стал воспринимать Vue как этакий конструктор и разработка на нем идет довольно быстро: если мне нужен, например, компонент выбора даты, скорее всего на Vue он уже существует, свободен в использовании и опробован сообществом. Я просто устанавливаю компонент в проект, пишу тег и все работает. По сути, наша панель состоит на 70-80% из готовых библиотек. Я имею в виду именно использование компонента, а не размер кодовой базы, который можно проверить командой типа: npx intrinsic/loc

При реализации проекта всегда учитываешь его перспективы, особенно перспективы развития. И то, что в экосистеме Vue уже имеются такие инструменты как Weex, Quasar Framework или Nuxt по мне существенно расширяют горизонты развития нашей панели.

На Хабре есть замечательная статья о Vue от его создателя, а я расскажу о некоторых особенностях нашего приложения.

Синхронизация Vuex с сервисом RestAPI
Часть данных глобального хранилища Vuex в нашем приложении синхронизируется с RestAPI путем обыкновенных запросов по соответствующим адресам. Зачем мы так сделали? Ну хотя бы для того, чтобы основные настройки пользователя не были привязаны к конкретному браузеру конкретного устройства. Можно зайти в нашу панель с компьютера жены или из игрового клуба и при этом получить в то же знакомое окружение, что и было у вас на своей родной машине.

Кроме того, когда синхронизация была только с localStorage, некоторые браузеры при обновлениях теряли содержимое localStorage — оно полностью удалялось. Да и в последнее время прослеживается какая то тенденция к ужесточению политики хранения данных пользователей в куках, например функция в WebKit Intelligent Tracking Prevention — не ровен час они доберутся и до localStorage.

Шина событий
Да, мы используем глобальную шину событий. Как и в любом другом крупном приложении с множеством компонентов, рано или поздно возникает необходимость наладить взаимодействие между не связанными между собой компонентами. Даже через глобальное хранилище. Понятно, что если есть связь родитель-потомок, их взаимодействие стандартно организуется через свойства props в одну сторону и методом $emit в другую, ну или через хранилище, как и описано в рекомендациях Vue.

Но в документации описана и возможность использования глобальной шины событий. У нас в проекте куча форм с разными наборами полей и в некоторых случаях (их немного, но все из них принципиальные) нужно как-то по особенному реагировать на изменение значения поля. Хранить в глобальном хранилище значения всех полей каждой формы не имеет смысла:

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

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

Взаимодействие RestAPI с панелью
Для большей отзывчивости интерфейса в старом jQuery-фреймворке обратная связь от RestAPI к клиентскому приложению эмулировалась через хитрую систему таймеров: она производила опросы RestAPI с определенным интервалом и перерисовывала узлы DOM, которые затронули изменения.

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

Для решения этой проблемы в новой панели я решил использовать связку из модуля Nchan для веб сервера Nginx и новых возможностей HTML5-интерфейсов — EventSource и WebWorker.

Модуль Nchan поддерживает отправку сообщений через Websocket, EventSource и Long-Polling. Я провел несколько тестов и решил использовать EventSource: сообщения могут быть только текстовыми и поток сообщений осуществляется только в одну сторону (от сервера). Это полностью решало поставленную задачу.

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

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

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

Я всегда проверяю пакеты на наличие хуков preinstall, install и postinstall в поле “scripts” файла “package.json”. Кроме того, использую статические анализаторы пакетов, такие как retire, snyk и команду “audit” пакетного менеджера npm.

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

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

После того, как пакет прошел анализ, я обязательно фиксирую его версию. Если нужна другая версия — пакет проходит анализ заново. Да, это занимает время, но оно того стоит.

Пока бэкдоры ни разу не попадали к нам на продакшн.

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

За что я полюбил новый фронтенд и панель в целом

• Стало проще поддерживать код

Разработка заняла полгода. Теперь я скорее занимаюсь поддержкой панели, свой код не жмет и не натирает.

Клиенты могут быстро получать то, что запрашивали


Стало быстро и удобно добавлять новые функции, которые появились в бекенде: например, оплату для юридических лиц я добавил за 2 дня, снепшоты — за 1 день.

https://vdsina.ru

Завоз железа. Засетапили новую партию железа в лучшем дата-центре Москвы — DataPro. В данный момент доступны: Стандартные серверы vdsina.ru/pricing (CPU 3.2 GHz), Hi-CPU vdsina.ru/pricing/hi-cpu-vds (CPU 4.5 GHz), Выделенные серверы vdsina.ru/pricing/dedicated-server (CPU 4.2 GHz).



500(!!!) Мбит/сек скорость подключения КАЖДОГО сервера (VDS / VPS / cloud / instance / хуинстанс) клиента сверх-хостинга серверов на ЛЮБОМ ТАРИФЕ! Это невероятно, НО в стоимость тарифов входит защита от ddos-атак!

vdsina.ru/tech/api
https://vdsina.ru

Мы «Хостинг технологии» и 5 лет назад запустили VDSina — первый vds хостинг, созданный специально для разработчиков. Мы стремимся сделать его удобным, как DigitalOcean, но с русской поддержкой, способами оплаты и серверами в России. Но DigitalOcean это не только надежность и цена, это еще и сервис.

Софт от ISPsystem оказался веревкой, которая связывала нам руки на пути к крутому сервису. Три года назад мы использовали биллинг Billmanager и панель управления серверами VMmanager и быстро поняли, что оказывать хороший сервис без своей панели практически нереально.

Как ISPsystem убивал удобство
Баги
Мы не могли сами пофиксить баг — каждый раз приходилось писать в чужую поддержку и ждать. Решение любой проблемы требовало реакции сторонней компании.

Поддержка ISPsystem нормально отвечала, но фиксы приходили только через несколько релизов, и то не всегда и не все. Иногда критические баги правились несколько недель. Нам приходилось успокаивать клиентов, извиняться и ждать, пока ISPsystem починят баг.

Угроза даунтаймов
Обновления могли порождать непрогнозируемые даунтаймы, которые провоцировали новые ошибки.

Каждый апдейт был лотереей: приходилось прикрывать биллинг и приносить жертвы богам обновлений — пару раз апдейт вызывал даунтайм на минут 10-15. Наши админы в это время седели на глазах — мы никогда не знали, сколько продлится даунтайм и не могли спрогнозировать, когда ISPsystem решит выпустить новый апдейт.

На пятом поколении Billmanager стало получше, но чтобы получить доступ к необходимым фичам пришлось ставить бету, которая уже обновлялась каждую неделю. Если что-то ломалось, приходилось давать доступ чужим разработчикам, чтобы они что-то поправили.

Неудобный интерфейс панели
Всё было разделено на разные панели и управлялось из разных мест. Например, клиенты платили через Billmanager, а перезагружать или переустанавливать VDS им приходилось в VMManager. Нашим сотрудникам тоже приходилось переключаться между окнами, чтобы помочь клиенту, проверить нагрузку на его сервере или посмотреть, какую ОС он использует.

Такой интерфейс отнимает время — и наше, и клиентов. Ни о каком удобстве, как у DigitalOcean, в такой ситуации речи не идёт.

Короткие лайфциклы с частым обновлением API
Мы писали собственные плагины — например, плагин с дополнительными способами оплаты, которых нет в VMManager.

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

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

Так созрело решение написать свою панель. Мы поставили цели:

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

И начали разработку.

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

Шаг 1. Серверный агент
Серверный агент — это веб-сервер на питоне, который управляет библиотекой libvirt, которая, в свою очередь, управляет гипервизором Qemu-kvm.

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

По идее libvirt можно было управлять прямо из биллинга, но это требовало слишком много дополнительного кода и мы решили разнести эти функции между агентом и биллингом — биллинг просто делает запросы агенту через JSON API.

Агент — первое, что мы сделали, поскольку он не требовал никакого интерфейса и тестировать его можно было прямо из консоли сервера.

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

Шаг 2. Биллинг
Для нашего разработчика Алекса это была уже не первая панель управления — Алекс в хостинге давно, поэтому он в целом понимал, что нужно клиенту и что нужно хостеру.

Биллинг мы и называем между собой «панелью управления»: в нем не только деньги и услуги, но и управление ими, поддержка клиентов и многое другое.

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

В новом биллинге использовали два стека: классический PHP, MySQL (а в будущем планируется перейти на PostgreSQL), Yii2 в качестве фреймворка на бекэнде и VueJS на фронте. Стеки работают независимо друг от друга, разрабатываются разными людьми, а общаются с помощью JSON API. Для разработки тогда и сейчас мы используем PHPStorm и WebStorm от JetBrains и нежно их любим (ребята, привет!)

Панель спроектирована по модульному принципу: модули платёжных систем, модуль регистраторов доменов или, например, модуль SSL-сертификатов. Можно легко добавить новую функцию или убрать старую. Задел на расширение заложен архитектурно, в том числе и в обратную сторону, «к железу».

Что мы получили: панель управления, над которой у нас полный контроль. Теперь баги правятся за часы, а не недели, а новые функции реализовываются по просьбе клиентов, а не по желанию ISPSystem.

Шаг 3. Интерфейс
Интерфейс — наше командное детище.


Сначала мы посмотрели, что будет, если сделать надстройку над API ISPsystem, ничего кардинально не меняя в интерфейсе. Вышло так себе и мы решили всё сделать с нуля.

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

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

Фронтенд
Панель решили сделать SPA приложением — нетребовательной к ресурсам и с быстрой загрузкой данных. Наш фронтендер Артыш решил писать ее на Vue — на тот момент Vue только появился. Мы предположили, что фреймворк будет развиваться динамично, как React, через какое-то время коммьюнити Vue разрастется и появится море библиотек. Мы поставили на Vue и не пожалели — теперь добавить на фронт новые функции, которые уже запрограммировали на бекенде занимает мало времени. Подробнее про фронтенд панели мы расскажем в отдельной статье.

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

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

Шаг 4. Тестирование и схема миграции
Когда все завелось и прошли первые тесты, встал вопрос миграции. Первым делом мы поставили биллинг и начали тестировать его работу с серверным агентом.

Потом написали простой скрипт, который переносит базу данных из старого биллинга в новый.

Приходилось тестировать и перепроверять буквально все, так как данные сливали в одну новую базу из трёх старых: Billmanager, VMmanager и IPmanager менеджера. Пожалуй, тестовые миграции — самое сложное, с чем мы столкнулись в процессе разработки новой панели.

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

Затем мы разослали письма клиентам с адресом новой панели и биллинга и сделали редирект.

В итоге: IT’S ALIVE!

Хэппиэнд
С первых часов работы своего софта мы почувствовали все прелести перехода. Код был полностью наш и с удобной архитектурой, а интерфейс — чистым и логичным.
Первый отзыв после запуска новой панели


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

Главное, что мы получили при переходе на свою систему (кроме общей надежности и удобства) — возможность быстро добавлять функционал под ключевых клиентов — быть к ним лицом, а не задницей.

Что дальше?
Мы растём, растёт количество данных, клиентов, данных клиентов. На бекенд пришлось добавить Memcached-сервер и два менеджера очередей с разными задачами. На фронтенде есть кэширование и свои очереди.

Конечно, у нас еще были приключения по мере разработки и усложнения продукта, например, когда мы добавляли HighLoad.

В следующей статье расскажем, как запускали Hi-CPU тариф: про железо, ПО, какие задачи мы решали и что у нас получилось.

vdsina.ru

Стоимость лицензии включена в тарифы.


https://vdsina.ru

В период с 1 по 12 мая включительно предоставляем скидку 50% на первый месяц пользования по любому выбранному тарифу!
Для получения скидки необходимо зарегистрироваться по ССЫЛКЕ.

Всем клиентам перешедшим с Timeweb на VDSina в период с 17 по 24 апреля удваиваем баланс аккаунта! Для получения бонуса создайте запрос в поддержку из личного кабинета.


https://vdsina.ru