Новые мощные серверы по низкой цене



Мы приготовили для вас, пожалуй, лучшее на сегодня решение по аренде физических (выделенных) серверов. Новое, только что купленное, мощное железо на базе процессора Intel Xeon E-2244G. Такой сервер обеспечит высокую производительность и стабильную работу крупного проекта.

Преимущества:
  • ваш сервер будет располагаться в дата-центре, спроектированном в соответствии со стандартом надежности Tier3;
  • 3 независимых магистральных провайдера, пропускная способность каналов — до 25 Гб/с при гарантированных 100 Мб/с, неограниченный трафик;
  • лучшая цена на рынке, просто сравните!

А еще:
  • крутая техническая поддержка, среднее время ответа — 34 минуты;
  • скидки до 7% при оплате на длительный срок;
  • серверы в наличии, время сборки — от 2 часов до 3 дней;
  • панель управления, позволяющая менять параметры конфигурации;
  • домен .RU/.РФ и 3000 рублей на рекламу в Google в подарок.

www.majordomo.ru/arenda-servera

Yandex.Cloud. Эпизод 1. Скрытые возможности дата-центров

Как устроены дата-центры? Почему мы сами проектируем и собираем стойки? Как мы определяем SLA и принимаем решения, которые непосредственно формируют надёжность и отказоустойчивость облачных сервисов? Открываем серию статей, в которых подробно расскажем о внутреннем устройстве нашей облачной платформы — от ЦОДов до работы технической поддержки, — а вы узнаете какие вопросы нужно задавать и какие меры принимать, чтобы ваша компания всегда была онлайн.



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

Но мало построить ЦОД и наполнить его оборудованием, нужно предусмотреть бесперебойную работу множества главных и вспомогательных систем. В первую очередь это касается электричества и охлаждения. Понимая, что серверные мощности будут расти с каждым годом, ЦОДы уже сейчас строятся рядом с дешёвыми и надежными источниками электроэнергии.

Все современные технологические гиганты, такие, как Google, Facebook, Microsoft и, конечно Яндекс, стремясь добиться максимальной надёжности и энергоэффективности, возводят распределённые сети собственных дата-центров. Именно в них и «живут» облака.

Tier дата-центра: так ли важен этот сертификат?
Главные показатели надёжности любого дата-центра — его отказоустойчивость и количество резервных инженерных систем. Опираясь на эту концепцию, в мире используется международный стандарт TIA-942 и система классификации института Uptime. Согласно нему, все ЦОДы характеризуется уровнем Tier и оценивается по 4-балльной системе:
  • Tier 1 — начальный уровень. В таких ЦОД нет запасных ресурсов и резервирования критически важных элементов. Допустимое время простоя в год — 28,8 часа, и, соответственно, показатель доступности и устойчивости к отказам в процентном соотношении — 99,671%. Выход из строя любой системы приводит к остановке и нарушениям работы всего дата-центра.
  • Tier 2 — закладывается резервирование и запасные ресурсы. Устанавливаются современные системы охлаждения и энергосбережения. Ежегодный простой — 22 часа, доступность — 99,7%. При замене неисправного оборудования или во время плановых работ полностью или частично останавливается работа ЦОД.
  • Tier 3 — можно ремонтировать и обновлять дата-центр без остановки и прекращения работы. В течение одного года простой ЦОДа третьего уровня составляет всего 1,6 часа, а устойчивость к отказу — 99,9%.
  • Tier 4 — сохранность данных и бесперебойная работа даже при поломке конкретного элемента и при возникновении системных сбоев. Полное резервирование всех компонентов. В течение 12 месяцев ЦОД четвёртого уровня может останавливаться только на 0,4 часа, а уровень устойчивости к отказам таких объектов составляет практически 100 процентов.

Проблема с такой классификацией в том, что на всех уровнях учитываются в основном схемотехнические и инженерные особенности. Изначально стандарт создавался для определения отказоустойчивости коммерческих дата-центров. Более того, получение сертификата Tier никак не измеряет реальное значение доступности услуг. Что же остается за кадром? Например:
  • Реальная надежность поставщиков электроэнергии.
  • Особенности эксплуатации каждого устройства, включая режим, в котором оно будет использоваться, показатели его собственной надежности, условия сопряжения именно этого оборудования с другими элементами системы
  • Человеческий фактор.

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

Также, в современных реалиях необходимо включить в уравнение надёжность сетевой инфраструктуры и компонентов облачной платформы, используемой провайдером ЦОД.

Новый уровень надёжности — сертификация на операционную устойчивость
Следует заметить, что Uptime Institute учитывает приведенные выше факторы и предлагает коммерческим ЦОД пройти сертификацию на операционную устойчивость. Процедура сертификации сфокусирована не на проектном решении или его реализации, а на том, насколько команда эксплуатации способна профессионально его обслуживать и применять процессы, обеспечивающие максимальную надежность работы оборудования и минимум ошибок при выполнении всех видов обслуживания.

Проанализировав содержание и смысл такой сертификации, команда эксплуатации Яндекса пришла к выводу, что она применима не только для коммерческих, но, с небольшими коррективами, и для корпоративных ЦОД. Как результат, в 2018 году мы в качестве эксперимента прошли сертификацию M& O, убедившись, что принципы, которые мы используем для работы в наших ЦОД полностью соответствуют тем же высоким требованиям, что выдвигаются и к лучшим коммерческим ЦОД. На сегодняшний день в России только три ЦОД прошли такую сертификацию. Сравните эту цифру с полусотней обладателей сертификата Tier: uptimeinstitute.com/uptime-institute-awards/list.

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

Стоит сразу отметить, что фактические показали непрерывной работы дата-центров, которые использует Yandex.Cloud, за три последних года не опускались ниже 99,9996%, что фактически выше уровня Tier 3.

Мы сами разработали стойки, серверы и системы управления для экономии денег, времени и электричества
Яндекс построил и использует три основных дата-центра: Сасово, Владимир и Мытищи, соединённых между собой оптической кабельной сетью с очень высокой пропускной способностью — несколько терабит в секунду. Они образуют распределенную систему, которая позволяет балансировать нагрузку и резервировать не только отдельные инженерные системы на уровне каждого ЦОД, но и сами ЦОД.


Конечно, основная задача дата-центра — хранение данных и выполнение вычислений. В Яндексе устанавливаются сервера и серверные стойки, произведённые вендорами по нашей спецификации.

До 2011 года оборудование было чужое. Это приводило к тому, что серверы от различных производителей по-разному вели себя под одинаковой нагрузкой. Встречались даже ситуации, когда потребление воздуха у одних было в несколько раз больше, чем у других, и их нельзя было ставить рядом. Сильно потребляющие воздух сервера «отъедали» его у своих соседей, создавая зоны локального разряжения. Это приводило к появлению дисбаланса и необходимости ручного управления, словом, к потере времени, энергии и денег.

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

Собирают стойки 3.0 на заводе в Китае, где налажена отдельная производственная линия. Во время сборки в систему управления стойки прошивается разработанное Яндексом программное обеспечение, основанное на проекте OpenBMC. Благодаря этому удалось реализовать алгоритм термостатирования температур процессоров — мы можем задавать их для каждой стойки (и даже для каждого сервера, но в этом обычно нет необходимости) с помощью внешнего интерфейса (API) системы управления.

Электричество в дата-центрах: прямое подключение и генераторы
Качественное железо, уникальные сервисы — всё это может пропасть в один момент, если правильно не спроектировать бесперебойное электроснабжение. Дата-центр может быть автономной структурой, но он всегда подключён к внешней электрической сети, а значит, не застрахован от форсмажоров. Однако, в зависимости от типа подключений и возраста оборудования можно достаточно достоверно спрогнозировать частоту проблем с электропитанием. Поэтому подход, избранный Яндексом — подключение по линиям высокого напряжения (110 кВ и выше) непосредственно к сетям национальных операторов со строительством собственных кабельных линий и подстанций.

Бесперебойность обычно обеспечивает классической схемой — комплексом «ИБП + дизель-генераторная установка (ДГУ)». Это классическая и отработанная годами схема работы для обеспечения бесперебойного питания в ДЦ. Она имеет массу плюсов — относительная простота, высокая надёжность, практически неограниченное время работы на дизелях. Но и свои минусы: как технические — необходимы достаточно большие площади для размещения оборудования, которые нужно обязательно оборудовать системами поддержания заданных климатических параметров, так и финансовые — при больших мощностях это решение получается достаточно дорогим.

В настоящее время Яндекс использует технологию ДРИБП — Дизельных Роторных Источников Бесперебойного Питания (DRUPS — Diesel Rotary Uninterruptible Power Supply). ДРИБП запасает не электрическую, а кинетическую энергию: внешнее электричество питает электромотор, который вращает огромный маховик и через дроссель вырабатывает «очищенное» питание. То есть ДРИБП выполняет функции стабилизатора и фильтра напряжения. Если внешнее напряжение пропадает, мотор превращается в генератор, вращение которого поддерживается вращающимся по инерции маховиком. В это время происходит запуск дизель-генератора.


В наших ЦОД используются ДРИБП разных производителей, отличающиеся в деталях реализации. Однако, в целом, такой вид ИБП показал свою жизнеспособность в условиях ЦОД. Конечно, как и всякое оборудование, эти сложные устройства требуют внимания и аккуратности при обслуживании. Поэтому внутри нашей команды эксплуатации организованы специальные группы специалистов по силовому оборудованию, обученные непосредственно производителями и способные решать большинство задач по обслуживанию ИБП без привлечения сторонних организаций.

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

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

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

Главное достоинство такой системы — сравнительно низкое потребление энергии, которая нужна только для работы вентиляторов, и простота — здесь нет громоздкого и сложного холодильного оборудования, которое может сломаться и нарушить стабильность работы. Именно фрикулинг позволяет Яндексу гордиться энергоэффективностью своих дата-центров последнего поколения: в Сасово и Владимире мы добились показателя PUE — эффективности использования энергии — в пределах 1,05-1,07. При этом надежность системы охлаждения возросла, так как количество компонентов в ней существенно снизилось.



9 ответов про дата-центры, которые помогут оценить надёжность облака
Итак, мы разобрались, что в основе надёжности любой облачной платформы лежит дата-центр или система дата-центров. Это значит, что первым делом при выборе «облака» вы должны задать следующие вопросы:
  • Сколько дата-центров обслуживает «облако»?
  • Где они расположены?
  • Как они связаны между собой?
  • Как обеспечивается надёжность и отказоустойчивость ЦОДа?
  • Достаточно ли компетентна команда эксплуатации выбранного ЦОД?
  • Какой уровень SLA предоставляет облачный провайдер на каждый из своих сервисов?
  • Какие сервера используются в ЦОД?
  • Как они управляются и как быстро могут быть заменены в случае аварии?
  • Как обеспечивается безопасность ЦОД? Электричество? Охлаждение?

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

Выделенный сервер по доступной цене

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


Предлагаем:
  • Скидки до 30% на готовые конфигурации серверов;
  • Второй сервер по акции на 10% дешевле;
  • При оплате от 6 месяцев дополнительные бонусы.
Поможем:
  • Держать ресурсы в безопасности. Мы заботимся о сборке, установке, физической сохранности и работоспособности серверов. Системные администраторы круглосуточно осуществляют мониторинг;
  • Найти ответ на любой вопрос. Квалифицированная команда технической поддержки поможет по телефону, в тикете, социальных сетях или мессенджерах 24/7;
  • Решить вопрос администрирования. Проконсультируем и предоставим выбор: управлять сервером самостоятельно или воспользоваться нашим администрированием;
  • Избежать лишних платежей. Бесплатно устанавливаем оборудование и обсуждаем сразу все детали оплаты услуги.



Если вы не нашли сервер под потребности вашего проекта, напишите нам на почту servers@beget.ru — мы обязательно придумаем решение специально для вас.


beget.com

SolusIO 1.1.12990 Released



SolusIO — Выпущена версия 1.1.12990
Мы с гордостью сообщаем, что выпустили новую версию SolusIO, SolusIO v1.1.12990. Эта версия содержит несколько приятных улучшений и новых функций.

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

Новые особенности
  • Добавлена возможность настройки IPv6 для виртуальных серверов.
  • Добавлена возможность установить «URL условий и положений»
  • Если включена интеграция биллинга, SolusIO теперь показывает общую цену, налоги и «условия» на странице создания виртуального сервера в области пользователя.
  • Добавлена возможность редактировать идентификатор пользователя биллинга в интерфейсе администратора.

Добавлена возможность настройки IPv6 для виртуальных серверов.
SolusIO автоматически проверяет, работает ли добавленный блок IPv6 для подключенного вычислительного ресурса. Чтобы увидеть результат проверки, перейдите в раздел «Вычислительные ресурсы» и щелкните имя вычислительного ресурса.


Для выполнения проверки SolusIO пингует шлюз каждую минуту. Цель — найти любой глобальный шлюз IPv6 в сетевом интерфейсе вычислительного ресурса.

Если проверка не удалась, вы увидите сообщение «IPv6 недоступен». Чтобы устранить эту проблему, необходимо проверить, настроен ли для вычислительного ресурса IPv6. У некоторых провайдеров IPv6 недоступен и не настроен по умолчанию.

Администратор может настроить блокировку IPv6 на странице «Добавить блокировку IP».


Подробности доступны в нашей общедоступной документации: docs.solus.io/en-US/latest/administration/adding-ipv6-blocks.11/

Добавлена возможность установить «URL условий и положений»
Администратор может добавить URL-адрес условий и положений в Настройки → Пользовательская область-> Брендинг.


«Положения и условия» будут отображаться в пользовательской области для конечного пользователя. Если включена интеграция биллинга, SolusIO теперь показывает общую цену, налоги и «условия» на странице создания виртуального сервера в области пользователя.


Добавлена возможность редактировать идентификатор пользователя биллинга в пользовательском интерфейсе админки.


Улучшения
Шина SCSI теперь используется для монтирования файлов ISO Cloud-init вместо IDE.

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

Конечная точка API «compute_resource_storages» была переименована в «хранилища»

Исправление ошибок
Исправлена проблема, при которой консоль VNC для ОС Windows отображалась в монохромном, а не в цветном режиме.

Исправлена проблема, когда смещение указателя мыши не работало правильно в консоли VNC для ОС Windows. (SIO-2170)

Адреса IPv6, включенные в IP-блок, теперь могут использоваться в качестве шлюза для этого IP-блока.

SolusIO WHMCS VPS Provisioning module released



Выпущен модуль подготовки SolusIO WHMCS
Мы с гордостью сообщаем, что выпустили модуль SolusIO WHMCS VPS Provisioning. Этот модуль дает вам возможность продавать VPS с предоплатой в традиционном стиле.

Модуль позволяет выполнять следующие действия виртуального сервера:
  • Создайте
  • уничтожить
  • приостановить
  • откладывать
  • перезагрузка
  • ботинок
  • неисправность
  • Монтаж
Загрузите последний пакет со страницы наших выпусков: github.com/solusio/solusiovps/releases
Извлеките содержимое zip-файла в корневой каталог WHMCS.

Конфигурация
Откройте страницу учетной записи в пользовательской области SolusIO, чтобы сгенерировать токен API.

Настройте доступ к SolusIO API, добавив новый сервер в WHMCS. Обязательные поля: Имя хоста и Пароль.

Токен API SolusIO необходимо сохранить в поле пароля.


Создайте группу серверов в WHMCS и назначьте сервер, который был создан на предыдущем шаге.


Конфигурация продукта

повторно создайте продукт в WHMCS и выберите SolusIO VPS в качестве связанного модуля и группы серверов, которую вы настроили ранее.

Выберите план, местоположение по умолчанию и операционную систему и сохраните изменения.

Дополнительная конфигурация
Локации
Модуль дает возможность выбрать конкретное место при заказе товара. Это делается в виде настраиваемых параметров.


Создайте настраиваемую опцию с именем Location. Добавьте параметры в соответствии со следующим соглашением: locationId | locationName. Это будет иметь приоритет над выбранным местоположением в настройках модуля продукта.

Операционные системы
Модуль дает возможность выбрать конкретную операционную систему при заказе товара. Это делается в виде настраиваемых параметров.


Создайте настраиваемый параметр с именем Операционная система. Добавьте параметры в соответствии со следующим соглашением: osId | osName. Это будет иметь приоритет над операционной системой, выбранной в настройках модуля продукта.

Ключ SSH
Модуль дает возможность указать SSH-ключ при заказе товара. Это делается в форме настраиваемого поля продукта.
Создайте настраиваемое поле с именем SSH Key и введите Text Area.

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

github.com/solusio/solusiovps/tree/v1.0.0

SolusIO 1.1.12097 Released



SolusIO — Выпущена версия v1.1.12097
Мы с гордостью сообщаем, что выпустили новую версию SolusIO, SolusIO v1.1.12097. Эта версия содержит несколько приятных улучшений и новых функций.

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

Новые особенности
SolusIO анонсировал новую функцию: изменение размера виртуального сервера.

Изменить размер виртуального сервера
Пользователь может обновить свой план на странице виртуального сервера в пользовательском интерфейсе.



Эта функция доступна в пользовательском интерфейсе администратора или API.

Возможность изменять размер ЦП и ОЗУ виртуального сервера только с возможностью возврата к предыдущему плану появится в ближайшее время.

Исправление ошибок
  • Исправлена ошибка, из-за которой не удалось создать моментальный снимок сервера, если моментальный снимок не удалось создать в течение одной минуты.
  • Исправлена проблема, когда уведомления по электронной почте о новых серверах на португальском языке содержали ненужный символ двоеточия («:») в паролях серверов.
  • Исправлена проблема, когда всплывающее окно создания проекта содержало нелокализованные заполнители в полях «Имя» и «Описание».
  • Исправлена проблема, когда брендинг не применялся к экрану входа в систему после выхода из области пользователя.

Plesk University
Не забывайте: доступен курс SolusIO Professional! Узнайте, как предложить масштабируемый интерфейс PublicCloud на основе API-интерфейса и самообслуживания для разработчиков и предприятий, использующих существующую инфраструктуру. Подпишите здесь!

Курс охватывает следующие темы:
  • Планирование вашей инфраструктуры SolusIO
  • Развертывание главного сервера SolusIO
  • Добавление вычислительных ресурсов
  • Настройка подготовки
  • Подготовка виртуальных серверов
  • Общее время: 2 часа

Выпущена стабильная версия Fleio 2020.09.1! Что нового?

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

В последнем выпуске мы завершили миграцию панели персонала с AngularJS на Angular. Кроме того, мы добавили дополнительные функции в кластеры и шаблоны кластеров, добавили настройки производительности и журналы для cron клиентов процессов, исправили ошибки и продолжили работу над подготовкой Fleio для Docker.

Угловой посох
В нескольких последних выпусках мы работали над переносом старой панели AngularJS Staff на Angular. Мы рады сообщить, что миграция завершена и на панели персонала есть все функции, доступные на Angular.

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

Улучшения кластеров и шаблонов кластеров
В выпуске 2020.09 мы работали над добавлением новых функциональных кластеров и шаблонов кластеров.

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

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


Также мы добавили способ получения файла конфигурации для развернутых кластеров.


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

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

Это можно настроить в файле settings.py, следуя этому руководству.

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

Стоит упомянуть исправления ошибок:
  • Исправление № 3297: исправление графиков показателей экземпляра иногда опускается ниже 0
  • Исправление № 3448: очистить кешированные настройки при сохранении конфигурации openstack.
  • Исправление №3409: обработка ошибки 500 при получении параметров создания для клиента без проекта openstack.
  • Исправление № 3434: исправление разделения аромата с экземпляром после редактирования.
  • Исправление # 3470: заставить клиента подтвердить удаление диалогового окна спрашивает, следует ли удалить все ресурсы.
Fleio 2020.08 включает в себя еще много улучшений и исправлений ошибок. Полный список см. В полном журнале изменений 2020.09.
fleio.com/docs/changelog/v2020.09.1.html

fleio.com/demo
fleio.com/

Fleio 2020.09.0 Beta

Fleio 2020.09.0 Beta: завершена работа над Angular, изменения в кластерах, доработки процессов cron клиентов и многое другое

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

Угловое путешествие персонала
Мы рады сообщить, что с последним выпуском Fleio мы завершили работу над новым персональным интерфейсом. В последние несколько месяцев мы постепенно перевели персонал Frontend с AngularJS на Angular.

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

Мы хотели бы услышать ваши отзывы о новом составе Frontend!

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

Благодаря этому у нас есть несколько новых параметров в файле base_settings.py, которые позволят вам:
  • настроить изображение по умолчанию / совместимые изображения с COE
  • настроить сетевой драйвер по умолчанию
  • настроить список COE
  • Кроме того, мы также реализовали способ назначения определенных вкусов для определенных шаблонов кластера.

Твики обработки клиентов cron
В версии 2020.09.0 мы узнали о проблеме, связанной с кешем cron клиентов процессов.

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

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

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

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

Обязательный контроль доступа в облачных вычислениях



Современная система Linux очень безопасна, со встроенной защитой от вирусных атак и другими важными функциями безопасности. Однако в современном мире удаленного доступа и международной электронной коммерции ставки высоки, и некоторые ИТ-директора и сетевые менеджеры хотят знать, смогут ли они сделать свои системы Linux еще безопаснее. Другой вариант добавления еще одного уровня безопасности в вашу среду Linux — это интеграция обязательного контроля доступа (MAC).
www.linode.com/docs/security/

Обязательный контроль доступа — это концепция, выросшая из многоуровневых систем безопасности, используемых для хранения военных секретов и другой конфиденциальной информации. Лучший способ понять MAC — это рассмотреть, чем он отличается от традиционных систем дискреционного контроля доступа (DAC) на основе Unix, используемых в стандартных средах Linux.

Традиционная система Linux назначает ресурсу права чтения / записи / выполнения и позволяет владельцу или администратору предоставлять доступ пользователям и группам. Суперпользователь (часто называемый «пользователем root») имеет полный контроль над системой и может получить доступ или предоставить доступ к любому ресурсу. Если все ведут себя хорошо и никто не ошибается, это гибко, легко для понимания и очень безопасно. Но что, если владелец ресурса непреднамеренно предоставит доступ тому, у кого он не должен быть? Или, что еще более важно, что, если учетная запись пользователя будет скомпрометирована, и злоумышленник воспользуется гибкостью, встроенной в систему DAC, для повышения привилегий?

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

Двумя наиболее популярными инструментами для принудительного контроля доступа в Linux являются SELinux и AppArmor. Дистрибутивы на основе Red Hat, такие как CentOS 7 и CentOS 8, предварительно настроены для SELinux. Ubuntu и openSUSE используют AppArmor; однако разработчики всегда могут удалить AppArmor и настроить SELinux, если вы более привыкли к нему или считаете, что он лучше подходит для вашей среды. AppArmor и SELinux имеют форму модулей ядра Linux и могут быть настроены для работы в большинстве основных систем Linux, хотя степень технической поддержки может варьироваться.

В целом AppArmor проще настраивать и использовать; однако, хотя AppArmor очень безопасен — и значительно безопаснее, чем работа без обязательной инфраструктуры контроля доступа, — SELinux обеспечивает более глубокий и универсальный уровень защиты. AppArmor предназначен для защиты файлов и других ресурсов; однако он не предлагает эквивалентной защиты для процессов. Кроме того, поскольку AppArmor ссылается на ресурсы по пути, злоумышленник, который уже находится в системе, теоретически может сыграть некоторые трюки с жесткими ссылками, которые были бы невозможны при использовании SELinux на основе inode.
www.redhat.com/en/topics/linux/what-is-selinux
wiki.ubuntu.com/AppArmor

SELinux был первоначально разработан на основе исследований Агентства национальной безопасности (NSA), разведывательного агентства национального уровня Министерства обороны США. Он предлагает более надежный подход к контролю доступа. Однако, поскольку его сложнее настраивать и работать, можно ожидать, что это потребует дополнительного времени на настройку и более длительного обучения ИТ-персонала.

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

Присоединяйтесь к бета-версии Vultr Marketplace Publisher



В последние несколько месяцев команда Vultr была занята добавлением инструментов и новых точек присутствия, необходимых разработчикам для развертывания приложений по всему миру. Благодаря нашей простой в использовании панели управления, мощному API, высокопроизводительным вычислениям и одной из крупнейших мировых сетей Vultr продолжает предоставлять разработчикам гибкость, необходимую им при масштабировании в облаке.
www.vultr.com/api/
www.vultr.com/features/datacenter-locations/

Сегодня мы ищем первых тестеров для нашей предстоящей бета-версии Vultr Marketplace! Эта программа является расширением нашей существующей инфраструктуры One-Click Apps и позволяет проверенным поставщикам упаковывать повторно используемые приложения для развертывания на платформе Vultr. Клиенты ценят удобство и надежность наших предварительно упакованных приложений, и с помощью этой программы вы можете разместить свои готовые к запуску приложения во всемирной инфраструктуре Vultr.
www.vultr.com/features/one-click-apps/

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

Как создать приложения из Marketplace?
Мы разработали конвейер сборки, чтобы он был удобен для разработчиков. Мы используем знакомые инструменты, такие как GitHub, GitLab, Packer и Docker, вместе с Vultr API. Мы предоставим вам все необходимое для начала работы в приветственном наборе. Сегодня мы принимаем бета-заявки. Позднее в этом году мы начнем рассылку приглашений участникам программы.

Я в предвкушении! Как мне начать?
Мы тоже в восторге! Мы готовы помочь вам в адаптации и сделать вашу заявку успешной. Щелкните здесь, чтобы сообщить нам немного о своем приложении и своем бизнесе. Наша команда свяжется с вами и сообщит, что делать дальше.
www.vultr.com/marketplace/become-a-verified-vendor/