В таком случае нужно делать резервное копирование конфигурации и восстанавливать на новом экземпляре роутера. Что касается вашего конкретного примера, то Mikrotik Cloud Router нормально работает в нашем облаке. Единственное, что в нашем списке шаблонов готовых приложений нет Mikrotik, и вам придется самим покупать дистрибутив у производителя.
Нет смысла указывать цены на наши услуги, так как мы размещаем в основном business critical сервисы крупных и средних компаний. В стоимость, помимо непосредственно вычислительных ресурсов, входит масса других услуг (проектирование, бэкап, расширенная техподдержка и пр.). Для каких-то стандартизированных услуг для небольших заказчиков или физ.лиц прописывать публичные цены можно, но это не наша история. И да — за редким исключением цены не афишируют все провайдеры, работающие с крупным бизнесом.
В рамках нашего EBS допускается:
— создание/удаление/снапшотинг волюмов,
— онлайн подключение и отключение волюмов к ВМ,
— онлайн ресайз волюмов,
— онлайн смена IOPS.
Все это доступно через AWS API. С Persistent Volumes для Kubernetes не должно быть проблем, хотя такого кейса в нашем облаке еще не было.
Ebs у нас отличается только характеристиками. По сути, это такой же ebs.
У нас поддерживается 2 Volume Type'а: standard (на базе магнитных дисков, без гарантий по производительности) и io1 (на базе All-Flash массивов, с возможностью выбора IOPS и SLA). Сейчас мы в стадии завершения закрытого тестирования нового типа волюмов — st2 (наша модификация AWS'овского st1). Он тоже на магнитных дисках, константно ограничен по IOPS, ограничение в MB/s зависит от объема диска. Он без бёрстинга, но предполагает использование в качестве загрузочного устройства.
Конкурентами Амазон я бы назвал Microsoft и Google. Догоняют-догоняют, да никак не догонят.
Мы же скорее взяли Amazon API, как де-факто отраслевой стандарт и лучшую практику.
Что касается публичных цен, то мы в основном работаем со средним и крупным бизнесом.
А точнее с задачами по размещению в облаке business critical сервисов таких организаций.
В подобных проектах обычно используются не только вычислительные ресурсы из облака, но еще и услуги по расширенной технической поддержке, проектирование, бэкап, мониторинг и т.д.
Публичные цены хороши там, где сервис высоко стандартизирован, например, на рынке SMB и физических лиц.
Когда же проекты в облаке становятся хоть сколь-либо комплексными, то в публичных ценах теряется весь смысл.
Технически гарантия достигается благодаря:
— использованию высокопроизводительных массивов, которые имеют большой ресурс по IOPS;
— нашему планировщику, который распределяет виртуальные диски по разным массивам в зависимости от того, на сколько те утилизированы, и того, сколько производительности должен предоставить данный виртуальный диск;
— лимитированием нагрузки на каждый отдельный виртуальный диск, чтобы расчеты планировщика не были напрасными.
Компоненты кластера работают на нодах совместно с другими сервисными ролями Облака, SDS/SDC и вовсе работают на серверах-гипервизорах. ОС — CentOS 7.2. Надежность сейчас нещадно тестируется, результаты пока очень радуют. Больше технических и архитектурных подробностей вместе с ответами на все вопросы будет в готовящемся посте на эту тему.
Публичный репозиторий нашей команды тут: github.com/C2Devel. В него выкладываем модифицированные нами opensource решения. Также мы являемся контрибьюторами (пусть и не очень активными) в проектах, результаты которых мы используем в облаке (Ceph, Open vSwitch, различные модули Puppet). Есть и отдельные небольшие проекты, написанные нашими ребятами и выложенные в публичные репозитории.
Интегратор КРОК также ведёт деятельность в opensource-сообществе, но это уже не облачное подразделение.
Proxmox никак не относится к работе облака, используется только для внутренних сервисов службы эксплуатации. Proxmox использовался как единичный случай для установки драйверов.
Под разные задачи используются разные СХД, либо конвергентные системы, объединяющие дисковые полки в виртуальные СХД. К сожалению, вопрос поставлен так, что я не имею права называть вендора по одному из договоров, но если вы полистаете блог, то увидите, что и как часто мы тестируем. Как правило, это то, что потом внедряется и у нас, и у заказчиков.
Мы можем говорить только про своих облачных заказчиков: их количество увеличилось где-то на 25% с начала года (точные цифры пока не подбивали), постоянно приходят запросы на демо-доступ к облачным услугам. Среди заказчиков достаточно много иностранных компаний и тех, кто ранее размещался за рубежом. Есть предположение, что это происходит из-за закона о хранении персональных данных в России. Ну, и подросший курс валют сыграл нам на руку, так как тарифы у нас в рублях, а облако доступнее предложений аналогичного плана у иностранных коллег.
Если кратко, то мы используем SDN (в реализации VMWare NSX) ещё с тех пор, когда это не было модно, и продукт принадлежал стартапу Nicira. Физическая часть — Mellanox Inifiniband, по которому бегает и storage траффик. Стык физика-виртуализация — это специализированные appliance. Конечно, в рамках ответа невозможно полностью раскрыть тему сети в облаке, так как она очень и очень объемная. Возможно, будет полноценная статья на Хабре, следите за новостями.
По ФИО вообще все однозначно – см. п. 5 ч. 2 ст. 22 Федерального закона «О персональных данных». ФИО в отдельности, безусловно, отнесены законом к персональным данным. Вообще сложившаяся правоприменительная практика, а также ряд подзаконных актов в сфере персональных данных указывают, что перечисленные категории, каждая по отдельности, являются персональными данными.
Если я правильно понял, речь идет о хранении ПДн.
Хранение в статье 2 Федерального закона № 242-ФЗ названо среди способов обработки ПДн, которые нужно осуществлять с использованием баз данных, находящихся на территории Российской Федерации.
Не важно, для каких целей хранятся данные (для восстановления или иных). Если они хранятся, то первоначально при сборе должны храниться на территории РФ, но впоследствии могут быть продублированы за рубежом.
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
— создание/удаление/снапшотинг волюмов,
— онлайн подключение и отключение волюмов к ВМ,
— онлайн ресайз волюмов,
— онлайн смена IOPS.
Все это доступно через AWS API. С Persistent Volumes для Kubernetes не должно быть проблем, хотя такого кейса в нашем облаке еще не было.
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того
У нас поддерживается 2 Volume Type'а: standard (на базе магнитных дисков, без гарантий по производительности) и io1 (на базе All-Flash массивов, с возможностью выбора IOPS и SLA). Сейчас мы в стадии завершения закрытого тестирования нового типа волюмов — st2 (наша модификация AWS'овского st1). Он тоже на магнитных дисках, константно ограничен по IOPS, ограничение в MB/s зависит от объема диска. Он без бёрстинга, но предполагает использование в качестве загрузочного устройства.
P.S. CEPH с RBD мы не используем.
Как в 2009 году мы начали строить облако, и где ошиблись
Мы же скорее взяли Amazon API, как де-факто отраслевой стандарт и лучшую практику.
Что касается публичных цен, то мы в основном работаем со средним и крупным бизнесом.
А точнее с задачами по размещению в облаке business critical сервисов таких организаций.
В подобных проектах обычно используются не только вычислительные ресурсы из облака, но еще и услуги по расширенной технической поддержке, проектирование, бэкап, мониторинг и т.д.
Публичные цены хороши там, где сервис высоко стандартизирован, например, на рынке SMB и физических лиц.
Когда же проекты в облаке становятся хоть сколь-либо комплексными, то в публичных ценах теряется весь смысл.
Как в 2009 году мы начали строить облако, и где ошиблись
Технически гарантия достигается благодаря:
— использованию высокопроизводительных массивов, которые имеют большой ресурс по IOPS;
— нашему планировщику, который распределяет виртуальные диски по разным массивам в зависимости от того, на сколько те утилизированы, и того, сколько производительности должен предоставить данный виртуальный диск;
— лимитированием нагрузки на каждый отдельный виртуальный диск, чтобы расчеты планировщика не были напрасными.
Как в 2009 году мы начали строить облако, и где ошиблись
Как в 2009 году мы начали строить облако, и где ошиблись
Как в 2009 году мы начали строить облако, и где ошиблись
Как в 2009 году мы начали строить облако, и где ошиблись
Интегратор КРОК также ведёт деятельность в opensource-сообществе, но это уже не облачное подразделение.
Миграция инфраструктуры в «облако» по шагам: какие возникают сложности и где
Миграция инфраструктуры в «облако» по шагам: какие возникают сложности и где
Полный перевод облака КРОК на All-Flash хранилища данных Violin Memory
Полный перевод облака КРОК на All-Flash хранилища данных Violin Memory
Полный перевод облака КРОК на All-Flash хранилища данных Violin Memory
Что нужно знать про миграцию в Россию к 1 сентября 2015-го с иностранной инфраструктуры
Что нужно знать про миграцию в Россию к 1 сентября 2015-го с иностранной инфраструктуры
Хранение в статье 2 Федерального закона № 242-ФЗ названо среди способов обработки ПДн, которые нужно осуществлять с использованием баз данных, находящихся на территории Российской Федерации.
Не важно, для каких целей хранятся данные (для восстановления или иных). Если они хранятся, то первоначально при сборе должны храниться на территории РФ, но впоследствии могут быть продублированы за рубежом.
Что нужно знать про миграцию в Россию к 1 сентября 2015-го с иностранной инфраструктуры