1. Однораноговая сеть в ZT выступает транспортным слоем — VL1. VLANы — это уже VL2. Как это выгладит на практике — в отдельном посте.
Цитата из статьи
В следующей статье я планирую продемонстрировать на практике создание виртуальной сетевой инфраструктуры на основе ZeroTier, где в качестве сетевого контроллера будет использоваться VDS с шаблоном частного open source GUI.
2. Для организации сети ZT пользователю нужны только сами объединяемые ресурсы и доступ к контроллеру сети. Высокодоступные корневые серверы — забота провайдера.
Цитата из статьи
На данный момент основные (планетарные) корневые серверы находятся по управлением разработчика — ZeroTier,Inc. и предоставляются как бесплатная услуга.
RUVDS также имеет инфраструктуру корневых серверов (лун) и предоставляет доступ для клиентов к ней по free модели.
Цитата из статьи
Однако, существует возможность создания пользовательских корневых серверов (лун), которые позволяют:
уменьшить зависимость от инфраструктуры ZeroTier, Inc.; Ссылка на документацию
повысить производительности за счёт минимизации задержек;
продолжать работать в обычном режиме в случае потери интернет-соединения.
Необходимость создания собственных пользовательских корневых серверов у потребителя возникает только тогда, когда он желает обеспечить работу ZT во внутренней сети при потери доступа к интернет. Например, университетский кампус или территория обособленного предприятия
Вопросы практического использования ZT я, как раз, и буду разбирать в следующем посте.
Цитата из статьи
В следующей статье я планирую продемонстрировать на практике создание виртуальной сетевой инфраструктуры на основе ZeroTier, где в качестве сетевого контроллера будет использоваться VDS с шаблоном частного open source GUI.
Причём коснусь нескольких моделей. Объединение устройств, объединение сетей, "road warrior" подключение, гибридные модели.
Я считаю в РФ нету нормального облака. Ваша статья говорил что в РФ дофига облаков. Но стоит только начать их продавать, как начнутся те или иные проблемы. ....
Прежде чем выносить в заголовок материала "… облачные услуги", наверно стоит определиться, что же всё-таки такое — облака, облачные вычисления и т.д.
Размытие и подмена этих понятий на Российском ИТ-рынке, приводит к тому, что от лица некоторых маркетологов в области ИТ и телекоммуникаций определение этих терминов превращается в:
— «То что не интернет и телефония, то — облака!»
Я не призываю придумывать их (определения) заново. Ибо все уже придумано и стандартизовано давно, вот только российская модель «ху@к-ху@к, и в продакшен» и профессиональные компетенции в стиле «без лоха — жизнь плоха» поощряет сервис-провайдеров придавать новый смысл понятиям, уже имеющим свой собственный.
Для начала, согласно вышеуказанным стандартам, c позволения хабрасообщества хочу процитировать основные определения и характеристики облачных вычислений:
Облачные вычисления (Cloud Computing) — это модель обеспечения повсеместного и удобного сетевого доступа по требованию к вычислительным ресурсным пулам (например, сетям, серверам, системам хранения, приложениям, сервисам), которые могут быть быстро предоставлены или возвращены с минимальными усилиями по управлению и взаимодействию с поставщиком услуг.
Облачная модель обладает пятью основными свойствами, и состоит из трех моделей обслуживания и четырех моделей развертывания.
Основные свойства
Самообслуживание по требованию (On-demand self-service). Потребитель имеет возможность получить доступ к предоставляемым вычислительным ресурсам в одностороннем порядке, по мере необходимости, автоматически, без необходимости взаимодействия с сотрудниками каждого поставщика услуг.
Широкий сетевой доступ (Broad network access). Предоставляемые вычислительные ресурсы доступны по сети через стандартные механизмы для различных платформ, тонких и толстых клиентов (мобильных телефонов, планшетов, ноутбуков, рабочих станций и т.п.).
особые условия
Облачный сервис необязательно должен быть доступен для всех типов платформ и может ограничиваться одной платформой (например, MS Windows), если это соответствует целям и концепции сервиса, однако в случае излишне строгих требований к клиентской части могут привести к тому, что сервис не будет считаться облачным.
Объединение ресурсов в пулы (Resorce pooling). Вычислительные ресурсы поставщика объединяются в пулы для обслуживания множества потребителей по модели множественной аренды.
(multi-tenant)
— То есть каждый из заказчиков облачной инфраструктуры обслуживается в рамках своей аренды
Пулы включают в себя различные физические и виртуальные ресурсы, которые могут быть динамически назначены и переназначены в соответствии с потребительским спросом.
Нет необходимости в понимании или управлении со стороны потребителя точным местоположением ресурсов, однако возможно указать местонахождение на более высоком уровне абстракции (например, страна, регион или центр обработки данных). Примерами такого рода ресурсов могут быть системы хранения, вычислительные процессорные мощности, оперативная память, пропускная способность сети.
Мгновенная эластичность (Rapid elasticity). Ресурсы могут быть эластично выделены и освобождены (возвращены поставщику) в кратчайшие сроки, в некоторых случаях автоматически, для быстрого масштабирования соразмерно со спросом.
насколько быстро?
Максимальное время реакции на запрос потребителя об изменениях потребностей в ресурсах прописывается в соглашении о уровнях сервиса (SLA).
Для потребителя возможности для предоставления ресурсов могут видятся как неограниченные, могут быть присвоены в любом количестве в любое время.
Измеряемость (Measured service). Облачные системы и сервисы должны обладать функциями автоматизированного измерения, управления и оптимизации использования ресурсов на уровне абстракции, применительно для разного рода сервисов (например, объемы хранения, обработка, полоса пропускания, или активные пользовательские сессии). Использованные ресурсы могут отслеживаться и контролироваться, что обеспечивает прозрачность как для поставщика, так и для потребителя, использующего сервис.
Модели обслуживания
Программное обеспечение как услуга (Software as a Service — SaaS). Возможность предоставления потребителю в использование приложений поставщика, работающих в облачной инфраструктуре.
что такое облачная инфраструктура?
Под облачной инфраструктурой понимается набор аппаратного и программного обеспечения, имеющих пять основных свойств облачных вычислений. Облачная инфраструктура рассматривает как содержащая и физический уровень, и уровень абстракции. Физический уровень состоит из аппаратных ресурсов, которые необходимы для поддержки облака предоставляемых услуг, и как правило, включает серверы, системы хранения и сетевые компоненты.Уровень абстракции состоит из программного обеспечения развернутого в физическом уровне, и содержит все основные свойства облаков. Концептуально уровень абстракции стоит выше физического уровня.
Приложения доступны из различных клиентских устройств или через интерфейсы тонких клиентов, такие как веб-браузер (например, веб-почта) или интерфейсы программ. Потребитель, при этом, не управляет базовой инфраструктурой облака, в том числе сетями, серверами, операционными системами, системами хранения, или даже индивидуальными настройками приложений, за исключением некоторых пользовательских настроек конфигурации приложения.
Платформа как услуга (Platform as a Service — PaaS). Возможность предоставления потребителю для развертывания на облачной инфраструктуре потребительского, созданного или приобретенного приложения, созданных с помощью языков программирования, библиотек, служб и средств, поддерживаемых поставщиком услуг.
исключения
Эта возможность не исключает использования совместимых языков программирования, библиотек, служб и средств из других источников.
Потребитель, при этом не управляет базовой инфраструктурой облака, в том числе сетями, серверами, операционными система и системами хранения данных, но имеет контроль над развернутыми приложениями и, возможно, некоторыми параметрами конфигурации среды хостинга.
Инфраструктура как услуга (Infrastructure as a Service — IaaS). Возможность предоставления потребителю систем обработки, хранения, сетей передачи данных и других фундаментальных вычислительных ресурсов, в которых потребитель может развернуть и запустить произвольное программное обеспечение, включающее в себя операционные системы и приложения. Потребитель при этом не управляет базовой инфраструктурой облака, но имеет контроль над операционными системами, системами хранения и развернутыми приложениями, и, возможно, ограниченно контролирует выбор сетевых компонентов (например, хост с сетевыми экранами).
Модели развертывания
Частное облако (Private cloud). Облачная инфраструктура, подготовленная для эксклюзивного использования единой организацией, включающей несколько потребителей (например бизнес-подразделения либо входящие в состав единого холдинга организации). Такое облако может находиться в собственности, управлении и обслуживании самой организации, третьей стороны, или какой-либо комбинации из них, и находится как на территории организации, так и за ее пределами.
Облако сообщества (Community cloud). Облачная инфраструктура, подготовленная для эксклюзивного использования конкретного сообщества потребителей от организаций, имеющих общие проблемы (например, миссии, требования безопасности, политики, и общие требования). Облако может находиться в собственности, управлении и обслуживании одного или более организаций в сообществе, третьей стороне, или комбинации из них, и находится как на территории организаций, так и за их пределами.
Общее (или публичное) облако (Public cloud). Облачная инфраструктура, подготовленная для открытого использования широкой публикой. Оно может находиться в собственности, управлении и обслуживании деловыми, научными и правительственными организациями, или какой-либо их комбинацией. Облако существует на территории облачного поставщика.
Гибридное облако (Hybrid cloud). Облачная инфраструктура представляет собой композицию из двух или более различных инфраструктур облаков (частные, общественные или государственные), имеющих уникальные объекты, но связаны между собой стандартизованными или собственными технологиями, позволяющими переносить данные или приложения между компонентами (например, для балансировки нагрузки между облаками).
И задать авторам этого (и не только этого) сравнения поставщиков облачных услуг вопрос: — «Кто-нибудь, когда-нибудь будет сравнивать обозреваемые услуги на соответствие вышеописанным пяти основным свойствам, трем моделям обслуживания и четырём моделям развертывания? Или для вас тоже, что не интернет и не телефония — то облака?»
P.S. Перевод основных определений и характеристик облачных вычислений согласно NIST Cloud Computing
Standards Roadmap — Russian Cloud Computing Professional Association (RCCPA)
1. Однораноговая сеть в ZT выступает транспортным слоем — VL1. VLANы — это уже VL2. Как это выгладит на практике — в отдельном посте.
В следующей статье я планирую продемонстрировать на практике создание виртуальной сетевой инфраструктуры на основе ZeroTier, где в качестве сетевого контроллера будет использоваться VDS с шаблоном частного open source GUI.
2. Для организации сети ZT пользователю нужны только сами объединяемые ресурсы и доступ к контроллеру сети. Высокодоступные корневые серверы — забота провайдера.
На данный момент основные (планетарные) корневые серверы находятся по управлением разработчика — ZeroTier,Inc. и предоставляются как бесплатная услуга.
RUVDS также имеет инфраструктуру корневых серверов (лун) и предоставляет доступ для клиентов к ней по free модели.
Однако, существует возможность создания пользовательских корневых серверов (лун), которые позволяют:
Необходимость создания собственных пользовательских корневых серверов у потребителя возникает только тогда, когда он желает обеспечить работу ZT во внутренней сети при потери доступа к интернет. Например, университетский кампус или территория обособленного предприятия
Вопросы практического использования ZT я, как раз, и буду разбирать в следующем посте.
В следующей статье я планирую продемонстрировать на практике создание виртуальной сетевой инфраструктуры на основе ZeroTier, где в качестве сетевого контроллера будет использоваться VDS с шаблоном частного open source GUI.
Причём коснусь нескольких моделей. Объединение устройств, объединение сетей, "road warrior" подключение, гибридные модели.
Прежде чем выносить в заголовок материала "… облачные услуги", наверно стоит определиться, что же всё-таки такое — облака, облачные вычисления и т.д.
Размытие и подмена этих понятий на Российском ИТ-рынке, приводит к тому, что от лица некоторых маркетологов в области ИТ и телекоммуникаций определение этих терминов превращается в:
— «То что не интернет и телефония, то — облака!»
Я не призываю придумывать их (определения) заново. Ибо все уже придумано и стандартизовано давно, вот только российская модель «ху@к-ху@к, и в продакшен» и профессиональные компетенции в стиле «без лоха — жизнь плоха» поощряет сервис-провайдеров придавать новый смысл понятиям, уже имеющим свой собственный.
Для начала, согласно вышеуказанным стандартам, c позволения хабрасообщества хочу процитировать основные определения и характеристики облачных вычислений:
И задать авторам этого (и не только этого) сравнения поставщиков облачных услуг вопрос:
— «Кто-нибудь, когда-нибудь будет сравнивать обозреваемые услуги на соответствие вышеописанным пяти основным свойствам, трем моделям обслуживания и четырём моделям развертывания? Или для вас тоже, что не интернет и не телефония — то облака?»
P.S. Перевод основных определений и характеристик облачных вычислений согласно NIST Cloud Computing
Standards Roadmap — Russian Cloud Computing Professional Association (RCCPA)