Сергей Сверчков "Want to build a secure private cloud for IoT with high availability and scalability in mind? Learn how to from a real-life example developed for the healthcare industry"
•Télécharger en tant que PPTX, PDF•
0 j'aime•263 vues
We will share first-hand experience in how to build secure, highly available, and scalable private clouds for IoT industries, using OpenStack and Amazon Web Services. Join the talk to learn about unique techniques for connecting private customer networks to the cloud and providing support for WebSocket, TCP, and HTTP devices. This discussion will also cover Cloud Foundry, an open source cloud-native platform for rapid development of 12-factor applications.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Сергей Сверчков "Want to build a secure private cloud for IoT with high availability and scalability in mind? Learn how to from a real-life example developed for the healthcare industry"
Similaire à Сергей Сверчков "Want to build a secure private cloud for IoT with high availability and scalability in mind? Learn how to from a real-life example developed for the healthcare industry" (20)
Plus de Tanya Denisyuk
Plus de Tanya Denisyuk (13)
Dernier
Dernier (20)
Сергей Сверчков "Want to build a secure private cloud for IoT with high availability and scalability in mind? Learn how to from a real-life example developed for the healthcare industry"
- 1. Building an IoT cloud for the Healthcare: How to Solve Networking Challenges and Still Have High Availability
- 3. @altoros Implementation Requirements ● Build an IoT healthcare cloud solution: ○ Connect devices and users at customer sites ○ Thousands of devices ○ Dozens of customers ● Cloud implementation should be portable between ○ OpenStack running on HW ○ Public cloud provider like Amazon AWS
- 4. @altoros Implementation Requirements ● High availability and scalability: ○ A hardware AND/OR infrastructure platform ○ Cloud services and applications ○ Scalability (the scale can grow by a factor of 100) ● VPN connectivity is essential: ○ Devices with WebSocket, TCP, and HTTP ○ HTTP devices are bi-directional ○ Non-VPN connectivity should be supported
- 5. @altoros Technology Stack for Portable Platform ● Cloud Foundry PaaS ● Cassandra for device data ● MariaDB Galera for structured data ● RabbitMQ as message bus ● ElasticSearch, Logstash, Kibana (ELK) for logs ● Monitoring and alerting with Zabbix
- 6. @altoros Technology Stack for Portable Platform https://docs.cloudfoundry.org/
- 7. @altoros Technology Stack for Portable Platform https://docs.cloudfoundry.org/concepts/architecture/
- 8. When It Comes to HW and OpenStack
- 9. @altoros Cloud Platform on OpenStack: Deployment View
- 10. @altoros Cloud Platform on OpenStack: Network Model ● Cisco ASA 5545 as cloud firewall: ○ Up to VPN 2500 tunnels and 400 Mbps of encrypted traffic ○ Up to 300 VLANs ○ Supports Site2Site and administrative VPN ○ Can be clustered in Active / Standby mode ● Networks: ○ Administrative 10.30.0.0/24, native VLAN ○ Cloud “Public” 172.30.0.0/24, VLAN 101 ○ OpenStack management 192.168.100.0/24, VLAN 102 ○ OpenStack storage 192.168.200.0/24, VLAN 103 ○ Networks for VMs 192.168.[111-120].0/24, VLAN 110-120
- 11. @altoros Cloud Platform on OpenStack: Physical Networking
- 12. @altoros Cloud Platform on OpenStack: Services
- 13. @altoros Cloud Platform on OpenStack: Resources Cloud Attribute OpenStack Cloud VPN endpoint (HTTPS) Provider Public IP Domain name(s) *.cloud1.cloudprovider.CORP (internal DNS) *.vpn-cloud1.cloudprovider.com (public DNS) DNS servers 172.30.0.240 172.30.0.254 NTP servers ntp1.cloud1.cloudprovider.corp 172.30.0.252 172.30.0.253 Cloud Foundry API endpoint https://api.cf.cloud1.cloudprovider.CORP 172.30.0.80 172.30.0.81 VPN types: 1. Cisco Any Connect VPN adapter – Administrator 2. Site to Site VPN between networks - Cisco ASA to Cisco ASA - Checkpoint to Cisco ASA…
- 14. @altoros Cloud Platform on OpenStack: VPN Model Site2Site VPN: - For Customer 2 VPN Network Address Translation (NAT) is required. Use special NAT network 100.64.0.0/10 (RFC 6598)
- 15. @altoros Cloud Platform on OpenStack: VPN Networking VPN Type Networks Exposed DNS servers Cloud Foundry endpoints Cisco AnyConnect Administrative VPN 10.30.0.0/24 172.30.0.0/24 172.30.0.253 172.30.0.254 172.30.0.80 172.30.0.81 Site2Site VPN Only DNS and Cloud Foundry addresses 172.30.0.253 172.30.0.254 172.30.0.80 172.30.0.81 Site2Site VPN, with NAT Only DNS and Cloud Foundry addresses 100.64.30.253 100.64.30.254 100.64.30.80 100.64.30.81
- 16. @altoros Cloud Platform on OpenStack: DNS resolution options ● Configure DNS zone forwarding to cloud DNS server ○ Setup DNS zone forwarding in customer network zone: *.cloud1.cloudprovider.corp -- no NAT DNS servers: 172.30.0.253, 172.30.0.254 -- with NAT DNS servers: 100.64.30.253, 100.64.30.254 ● Use public DNS records for resolving private IP addresses ○ Create A-records at a public domain owned by cloud provider (sub-domains) Name: *.vpn-cloud1.cloudprovider.com Addresses: 100.64.30.80, 100.65.30.81
- 17. @altoros Cloud Platform on OpenStack: Domains and Routes ● Cloud Foundry routing to support internal and public DNS names: ○ Create shared domain(s): $ cf domains Getting domains in as admin... name status type cf.cloud1.cloudprovider.corp shared vpn-cloud1.cloudprovider.com shared tcp-cf.cloud1.cloudprovider.corp shared tcp ○ Map additional route(s) to an application: $cf map-route deviceserver vpn-cloud1.cloudprovider.com --hostname deviceserver
- 18. @altoros Cloud Platform on OpenStack: Device Connectivity
- 19. When It Comes to AWS
- 20. @altoros Cloud Platform on AWS
Notes de l'éditeur
- Добрый день коллеги. Я Сергей Сверчков, работаю руководителем проектов в компании Альторос. Сегодня я хотел был поделиться опытом одного из текущих проектов в компании, где мы разрабатываем облачную платформу для медицинской индустрии. Платформа оперирует сервисами для подключения и обработки данных с медицинских устройств, которые умеют обмениваться данными с серверами по стандартным интернет протоколам. Я не буду останавливаться на деталях бизнес-кейса, мы обсудим некоторые технические детали, из чего мы строим платфому и как делаем ее переносимой между различными инфраструктурами, такими как Amazon AWS и OpenStack.
- Итак давайте посмотрим на некоторые из требований проекта, чтобы мы могли описать выбор технологического стека, и обсудить какие сложные задачи приходиться решать в проектах такого уровня.
- С технической точки зрения, нам необходимо построить облачное решение, которое позволяет подключать умные медицинские устройства и пользователей, работающих в сети медицинских учреждений безопасным и надежным образом к облакеу Умные медицинские устройства могут передавать и получать данные с сервера использую интернет-протоколы. У многих организаций тысячи устройств и пользователей, и таких организаций может быть десятки. Для каждой организации должен быть обеспечено безопасное подключение и выделенное пространство в облаке для хранения и обработки данных с устройств. Мы называем это решение модной аббревиатурой IoT – Internet Of Things for healthcare. Планируется что решение будет переносим между облаком созданным на оборудовании в датацентре под управлением OpenStack и публичным cloud provider таким как Amazon AWS. Amazon AWS – это скажем так первый выбор среди публичных облачных платформ, но архитектура должна быть максимально независимой и пo возможности не использовать специальные сервисы AWS. Пару слов, а что же с точки зрения бизнеса является целью проекта. Существующее программное для работы с умными медицинскими устройствами работает у каждого потребителей на одном сервере без каких либо возможностей по масштабированию или отказоустойчивости. Таких установок сотни, и это ведет к огромным усилиям по поддержке и серверов и программного обеспечения для всех потребителей, а любое обновление растягивается на очень длительный период. Поэтому возникла идея о переносе программных сервисов в облако, чтобы добиться управляемости, масштабируемости и отказоустойчивости, а также сократить значительно расходы на поддержку.
- Можно представить, что когда речь идет о платформе для медицины, требование высокой доступности сервисов платформы является обязательным. И зачастую мы можем подумать, что когда мы строим платформу на облаке, например в Amazon AWS, высокая доступность сервисов и платформы в целом дается нам уже в готовом виде. Это может быть так только частично. Когда мы используем виртуальные ресурсы инфраструктурного провайдера, то нам необходимо позаботиться о высокой доступности и масштабируемости приложений и прикладных сервисов (например баз данных, очередей), а также подумать как создать избыточность виртуальных ресурсов. Дизайн и архитектура приложений должны учитывать требования высокой доступности с самого начала. Конечно когда мы говорим про cloud провайдера как Amazon AWS, мы не работаем с физическими серверами, сетями, роутерам, и источниками питания. Но вполне обычная ситуация, когда Amazon присылает уведомление, что виртуальная машина будет выведена из работы, и нам необходимо ее пересоздать и при этом потребители продолжают работать. Безопасность еще один ключевой аспект для любой организации (и особенно медицинской), начиная от защищенности персональных данных пациентов при передаче и хранении, до защиты периметра внутренней сети организации. Поэтому работа с облачным решением должна быть защищена с помощью VPN соединений. Причем требования к VPN соединениям достаточно жесткие и как мы недавно выяснили – стандартный Amazon VPN Gateway не отвечает всем необходимым условиям.
- Хорошо давайте посмотрим на наш выбор решений для построения переносимой платформы c отказоустойчивыми сервисами. Напомню мы говорим про переносимость между OpenStack и Amazon AWS. Cassandra cluster это выбор многих проектов где необходимо храниить данные с разбличных устройств. Это NoSQL база данных, которая предоставляет гибкую модель данных, репликацию, практически линейную масштабируемость с добавлением машин в кластере. Рекомендации разработчиков DataStax говорят о том, что запускать Cassandra лучше на железе, поэтому мы сделали большое количество тестов, чтобы понять какая будет производительность кластера на виртуальной инфраструктуре OpenStack и AWS. Результат тестов показал, что мы можем получать и записывать несколько тысяч пакетов данных размером порядка 1 Кб в секунду достаточно легко, и это укладывается примерно в оценку какое количество данных будет приходить с умных устройств. Также мы оценивали возможность запуска Cassandra через OpenStack Ironic project на железе. Для структурированных данных ограниченного размера мы выбрали MariaDB Galera cluster. Это проект созданный оригинальными разработчиками MySQL, который совместим c MySQL и расширен многими дополнительными функциями, в том числе поддержкой кластерной конфигурации с синхронной репликацией транзакции для отказоустойчивости. Рекомендуемый минимальный размер кластера это 3 машины, каждая машина содержит полную копию данных. Тестируя MariaDB Galera мы нашли что он практически не масштабируется по скорости записи, но в нашем случае большая часть операций – это чтение данных. Самый важный фактор в производительности - скорость записи в файлы журнала транзакций. Кластер RabbitMQ используется для всех асинхронных операций получения и отправки данных с устройств. Мы также тестировали его производительность, чтобы понять сможем ли мы сохранять для обработки несколько тысяч пакетов данных в секунду. Проект кластер ElasticSearch был выбран для хранения всех типов журнульных событий в приложениях или дословно говоря логов. Обработка логов делается с помощью проекта LogStash. Доступ и поиск в журналах событий через web interface Kibana. Мониторинг и нотификации о проблемах для всех виртульных ресурсов, железа, OpenStack настроен через Zabbix. Zabbix работает через агентов которые собирают метрики и отправляют на сервер. Основная сложность с Zabbix – это настройка производительности базы данных, которая может легко быть размером в сотни гигабайт метрик за период в несколько месяцев для нескольких тысяч метрик.
- А что же мы выбираем в качеств платформы для приложений и зачем она вообще нужна. Платформа приложений или PaaS дает возможность абстрагирования от инфраструктуры и автоматизирует управление состоянием приложений: развертывание, запуск, удаление приложения, а также мониторинг состояния и масштабирование приложений. В нашем случае различных приложений – десятки, они разработаны как микросервисы, поэтому ручное развертывание и управление состоянием приложений на инфраструктуре сложная задача. Мы решаем ее с помощью открытой платформы Cloud Foundry. Как мы можем увидеть на странице документации проекта, Cloud Foundry обеспечивает свободу выбора инфраструктуры – а это AWS, OpenStack, VMWare, Google Cloud, Azure, свободу выбора фреймворков разработки, а также единый подход по работе с сервисами приложений, как-то базы данных, очереди, объектные файловые хранилища и т.д.
- Коллеги, кто слышал про Cloud Foundry? А кто пробовал в работе? Отлично. Не будем вдаваться во все компоненты архитектуры, отмечу основные блоки. Взаимодействие с Cloud Foundry для разработчика – это простая и понятная командная консоль, через которую мы подключаемся с Cloud Foundry и выполняем публикацию приложений и управляем их состоянием. Архитектура Cloud Foundry модульная, открытая и расширяемая. Включает само-управляемый движок для выполнения приложений – в текущей версии это Diego cell – можно рассматривать это как виртуальную машина. В основе движка для приложения – Linux containers, в Cloud Foundry это Garden, управляющий контейнерами приложений на виртуальной машине. Т.е. когда мы хотим запустить приложение, Cloud Foundry выбирает автоматически виртуальную машину и создает на ней контейнер и загружает туда Application Runtime вместо с кодом приложения. Cloud Foundry следит за состоянием контейнера с приложением, если необходимо перезапускает приложение или пересоздает контейнер. Приложения для платформы приложений Cloud Foundry должны быть разработаны с учетом определенных факторов, например не хранить свое состояние на файловой системе. Совокупность этих требований называется 12 факторов. Взаимодействие с внешними сервисами стандартизировано через механизм сервис брокеров, отвечающих за создание например базы данных на сервере MySQL. Программные фреймворки описываются механизмом так называемых buildpacks, и дает возможность их расширять. Сущестующие билдпаки поддерживают практически все популярные языки и фреймворки на данный момент. Взаимодействие с внешним миром для контейнеров приложений обеспечивается через роутеры Router. Сейчас поддерживаются routing для HTTP(S), WebSocket и TCP протоколов.
- So let’s see how the cloud platform was implemented on OpenStack first and after that we’ll briefly look at the AWS implementation.
- When it comes to OpenStack cloud we need to choose hardware to deploy OpenStack in high availability mode. One option is to use blades chassis that can be mounted in datacenter racks. There are number of vendors to choose from: Dell, Supermicro, HP. But the recommended deployment is vendor-independent. At least three physical nodes or blades are used for the OpenStack management components. And OpenStack compute services are distributed across three availability zones. Each availability zone represents a group of 3 or more physical nodes. This creates redundancy on the hardware layer. It also allows us to distribute virtual machines evenly in each availability zone. One of the reasons why we created 3 zones is because most Cloud Foundry jobs and cloud services require 3 or more virtual nodes for high availability. So OpenStack is our infrastructure platform to run Cloud Foundry and cloud services, such as as Cassandra, MariaDB, and RabbitMQ. Some of the administrative services, like DNS, NTP, and OpenStack deployment tool are configured on additional nodes (or blades) outside of OpenStack. For these services, we use VMs running on a free-licensed ESXi hypervisor. This approach for deployment means that we can scale OpenStack’s computing and storage capacity simply by adding new blades or chassis.
- To secure our private cloud, we use Cisco firewall ASA 5545 (I’m speaking about our research and development environment). ASA 5545 can support over two thousand of VPN tunnels with a total bandwidth of 400 Mbit / sec. It is important that Cisco firewall supports site-to-site VPN connections from remote networks to the cloud and personalized administrative VPN connections proveded by the Cisco AnyConnect VPN adapter. We also verified that Cisco firewall can be clustered in Active / Standby mode, even though Cisco failures are quite rare. On this slide you can see some example of network configuration in our OpenStack cloud deployment. 10.30.0.0/16 – this is the administrative network for physical nodes. Available only for administrative VPN connections. 172.30.0.0/24 – and this is our “Public” cloud network which is a floating network in OpenStack. There are 2 OpenStack internal networks that are used for storage and management traffic in OpenStack. For virtual machines, we have allocated about 6 subnets with a separate virtual LAN for each subnet. Access and routing between administrative network and “public” cloud network is controlled by Cisco ASA. Also Cisco ASA controls what VPN can access what network and even specific addresses. It means that for site2site connectivity from customer network we expose only the addresses of services that should be available to the customer. Let’s see what the network diagram looks like for our research and development environment.
- This network diagram represents one of our R&D environments in the datacenter. It uses a SuperMicro blades chassis with 16 blades as hardware for the OpenStack deployment. 3 nodes are dedicated for OpenStack management services. 2 blades host the free ESXi hypervisor with administrative services and 11 nodes are grouped into 3 zones for OpenStack compute and storage services. All chassis blades are connected to a Cisco switch using 2 physical network interfaces. The Cisco firewall has an external interface configured with a public IP address supplied by the datacenter. Two internal interfaces in the Cisco firewall represent the administrative network (10.30.0.0/24) and the cloud’s public network. This is required if we want to control access to these networks via VPN connections. Cisco ASA also controls access to the internet outside of the cloud for all VMs and services. At lest two services, time and mail, need access to the outside world. All the blades in the chassis have pretty much identical configuration with 8 CPU cores and 2 hard drives. The OpenStack virtual router manages network traffic between the internal network of VMs and the floating network. Colored lines represent the networks in our cloud.
- Ok, let’s take a look at the distribution of Cloud Foundry and cloud services by OpenStack availability zones. Most Cloud Foundry jobs are replicated in 2 or 3 availability zones. These jobs include load balancers, routers, and cloud controllers. 3 to 6 application runners (Diego cells) are placed in each availability zone. For CF jobs that are not HA-ready, we decided that we can restore them with BOSH. We applied the same distribution approach for Cassandra, MariaDB, and RabbitMQ clusters, placing at least 1 VM in each zone and configuring replication. Administrative services run on additional physical blades and they are also replicated. For example, there are 2 NTP servers, working independently and 2 DNS servers in a master – slave configuration. Administrative nodes also run the OpenStack deployment tool. For our case, it’s Mirantis FUEL, which is backed up regularly. To sum up what we have seen so far – to build a highly-available cloud solution we need to think about resilience on each layer – from hardware to the applications stack.
- Let’s review how our private cloud represents it’s services to the consumers. There is a single VPN cloud connection endpoint. The main domain is a private domain name. Let’s call for example cloud1.cloudprovider.corp. “Cloud1” – is the designator of a cloud location or a region and “cloudprovider.corp” is like a internal domain. We also have public domain records that are used to resolve private addresses. Cloud Foundry has 2 endpoints and a it uses subdomain within our main domain name. As I mentioned, the Cisco firewall provides site2site connection for the remote network and personal VPN accounts for administrators. All activities for establishing and disconnecting VPN tunnels are logged and notifications are sent to a security administrator. For site2site connections, we support hardware or virtual firewalls by different vendors, like Checkpoint, Juniper, and Cisco, if they meet the encryption requirement of the cloud. Ok let’s see the VPN network diagram.
- So in the Cisco AnyConnect VPN connection (represented by a purple circle on left side) we expose both internal and “public” networks of our cloud to an administrator. It allows us to manage and configure the physical nodes, network switches, the Cisco firewall, and OpenStack deployment remotely. In our example diagram, we have 2 customer networks. Customer 1 (in the upper left corner) has its own subnet 172.30.0.0/16 that overlaps with our cloud’s public network. To solve the problem of overlapping we are using the Network Address Translation technology or NAT. We use subnets from a special network range 100.64.0.0/16 defined by RFC 6598. This RFC specifies network ranges to be used exclusively as the way to connect 2 private networks. In our deployment, the network address translation in both directions is handled by the Cisco firewall. Moreover, we can configure different rules for NAT based on remote subnet ranges. Let’s see how this works in terms of accessing the cloud’s resources.
- As I have mentioned, for Cisco AnyConnect we allow access to 2 cloud networks, without restriction. Site2site VPN connections get access only to DNS servers and Cloud Foundry endpoints. And in case of a VPN connection with NAT these addresses are translated to addresses from the 100.64.30.0/24 range. It is quite easy to map and remember the original and translated addresses.
- Ok, we have talked about VPN and accessing cloud resources by IP addresses. How about accessing applications in Cloud Foundry using domain names? For DNS resolution processes we designed 2 approaches. The first one is DNS zone forwarding to DNS servers in the cloud, e.g., for zone “cloud1.cloudprovider.corp”. With the 2-nd approach, we create A-records at a public domain owned by health cloud provider and use them to resolve IP addresses from the cloud. This approach has it’s cons as well, because 1 DNS records can be mapped to only one pair of addresses, e.g. we can’t mix NAT and non-NAT addresses for one DNS record.
- To support private and public domains for applications in Cloud Foundry we need to register shared domains and then add additional routes. In our example, the main domain in Cloud Foundry is “cf.cloud1.cloudprovider.corp” (highlighted in red). And we create an additional domain, called “vpn-cloud1.cloudprovider.com”, for resolving Cloud Foundry endpoints using a public DNS. In our example “vpn” stands for the VPN connection to the cloud. Of course, both domains are for private cloud addresses.
- Now let’s discuss some of the key aspects related to connecting devices to the private cloud on OpenStack. The diagram on the slide shows 2 customer networks with overlapping network ranges. I’ve already explained that we need to setup NAT rules to expose cloud services, specifically for Cloud Foundry. If we review the communication flow for devices that use the TCP and WebSocket protocols, we will see that they establish persistent connectivity. And the Cisco firewall supports hundreds of thousands of such connections and encryption bandwidth of up to 400 Mbits / second. TCP routers are used to connect TCP devices, and regular CF routers maintain connections of devices with the WebSocket protocol. So no real problems these devices – we just need to adjust settings of routers (the number of opened files and sockets, types of VM instances, etc.). But some legacy HTTP devices may use a mode when the server can initiate the HTTP request to the device. And with 2 remote networks (as in our example diagram) we have 2 HTTP devices with the same internal network address (The are shown as red and blue squares on left side). Cisco ASA can’t route such requests without knowing what VPN to use. To solve this problem, we introduced Proxy servers that are allocated inside the cloud within the network range 100.64.100.0/24. Each combination of a Proxy VM, VPN connection, and HTTP device in the customer’s network should be unique. In this case, the Cisco firewall will route requests through the correct VPN. The routing table in Cisco ASA is virtual and updated when HTTP requests are sent back and forth. This unique, yet simple implementation approach is based on the standard IPv4 protocol and doesn’t use expensive networking hardware with customized TCP stack (for example Cisco Application centric infrastructure).
- So let’s see what changes when we deploy this cloud platform in AWS
- In AWS, we use a virtual private cloud to deploy the Cloud Foundry and backend services. In order to avoid overlaps with customer networks, we decided to use a VPC network from the NAT range. Also we identified that the native Amazon VPN Gateway doesn’t support all the settings that are required for healthcare use cases. So we are running Cisco ASA as the virtual firewall. And it has almost the same functionality as a hardware firewall. So we just need to adapt our implementation of the OpenStack deployment to provide device connectivity. This proves that our architecture can be fairly easily moved between AWS and OpenStack infrastructures. There are lot of other challenges that we resolved in the project that I coud easily share within short time of presentation, but I’ll be glad to answer you questions now and after the session.
- Thank you very much and I’ll be glad to answer your questions.