About the state of affairs in OpenStack for service providers
Posted by: Paul Robers
At the last few jobs, I dealt with service providers (service providers of communication / managed services) from Iceland to Tokyo, and they all know that the unconditional leader ("800-pound gorilla") - the public cloud - follows their soul. For a while, they all tried to “pretend to be dead”, but the “gorilla” didn’t care and she continued to run in their direction. During all my trips, I did not doubt one thing: service providers must recognize that something needs to be drastically changed. How can they come to this?
')
Author photo : Ryan Poplin (Ryan Poplin)
Part of my job today is visiting customers to tell them what the OpenStack platform is, what its capabilities are, and whether they can integrate it with their infrastructure. One thing is clear: in order to get involved in the fight against public cloud vendors, the service provider needs to revise and refine its cloud service offerings, shifting the focus to software-defined technologies and automation.
If you look at the public cloud ecosystem, we will see that one of the most serious competitive advantages of the platform are the opportunities for automation. Unfortunately, many service providers today use old hardware and software infrastructure. I recently met with several service providers operating on outdated infrastructure, who, sadly, believe that automation is based on the speed with which their engineers are able to rotate in their chairs. To compete with large public clouds in today's market, service providers are exploring infrastructures such as OpenStack to regain the proper architectural foundation.
From time to time I came across quite sophisticated service providers who built their own clouds based on OpenStack. The conversation with them was about the following:
Me: It's great that you are working on the OpenStack platform. How are things going with her?
They: This is a nightmare! We spent weeks trying to figure out how to set everything up, and our engineers have to look for answers through the IRC chat and on the forums!
I: Wow!
I believe that many of you are the owner or tenant of your house, which requires basic care and maintenance. I am sure that most of you are not mechanical engineers or designers and have no idea how everything is assembled and working in your house. This is not required of us.
As for OpenStack, then you can draw an analogy with the house. OpenStack is based on many open source, complex projects that are linked through complex APIs that even the most experienced infrastructure support engineers are fighting. From a financial point of view, the choice of this path at the initial stage is likely to have a serious impact on revenues due to unmet business goals and failure to meet deadlines. With the do-it-yourself approach, a lot of people start working with OpenStack and, as a rule, fail, which leaves a very unpleasant aftertaste.
The main business objective of any service provider is to help design and ensure reliable hosting of customer applications. The key to success with OpenStack is to bring in a vendor who has gathered all the necessary code snippets and will provide the service provider with the enterprise level support he needs to run the business. Please, entrust technical support and packaging OpenStack proven vendor.
Today, OpenStack provides a framework by which customers can simplify infrastructures built on heterogeneous technologies by abstraction and combining various software interfaces into one common infrastructure or one API. The most important thing is to increase the efficiency of the data processing center (DPC).
From a network perspective, currently, OpenStack provides ways to integrate with such well-known devices as F5 Big-IP, Cisco Nexus, Citrix Netscaler, and Arista switches (integration with more devices is expected). As for storage, everything from EMC, NetApp, Coraid to Nexenta is integrated with OpenStack . Regarding hypervisors, you can choose from options such as VMWare, KVM, Xen, and HyperV . The service provider can use an infrastructure-independent approach to the data center and allow OpenStack to solve all complex tasks.
According to a user survey at the OpenStack summit in Atlanta, the number one business incentive for using OpenStack is the ability to avoid binding to a single vendor platform. Service providers rely on work with partners in the production of hardware and software (software) that do not point at each other with a finger when solving urgent tasks. Service providers also need to be able to establish strong strategic relationships that will enable them to activate the development plans of products of a particular vendor. If such a relationship is impossible, the service provider is extremely difficult to succeed. OpenStack gives service providers the flexibility that will allow them to get rid of vendors at any time and decide which combination of hardware and software will work in the best way for them and their customers.
OpenStack includes about a dozen projects, but outside the kernel, some of the projects may be of more interest to service providers than others. For example:
In the past, I worked at Carpathia Hosting , a company offering cloud services for businesses. Around 2009, I was working at a startup that provided VM lifecycle management solutions and features similar to those offered by the OpenStack Heat project. In fact, I needed a way to describe my data center through a conceptual project (blueprint) or code that I could save. Then I wanted to have the operational ability to programmatically instantiate new data center blocks from this blueprint. In other words, this startup provided a tool that allowed me to build a Data Center Class, after which I could instantiate new Objects. Very cool! Heat works the same way. This is a way to orchestrate your OpenStack environment with patterns compatible with the AWS Cloudformation service. I highly recommend using the Heat template every time you deploy OpenStack to achieve a high level of automation. You can find a good guide to Heat here .
All service providers need the ability to determine the amount of resources consumed and the period of their consumption. As mentioned above, if you use an environment that does not depend on hardware, as well as incompatible types of networks and data warehouses, you need a single, unified method of tracking used resources to simplify monitoring and management. A ceilometer is an OpenStack project used by service providers to provide measurement data, which can then be integrated into the billing system. More information can be found in the documentation .
Many service providers use different (often complex and headache) ways to automate the builds of their “clean” servers, but I’m now developing an Ironic project in OpenStack, which will give them this opportunity using a single API. Some companies, such as Rackspace, have announced their intention to submit their own version of Ironic called OnMetal. The value of this project is more than just a single API; service providers will be able to take advantage of all the features of OpenStack, including measurements, orchestration, block data storage, etc., on “clean” servers.
Ironic originated from the Nova Bare Metal project, which was then collapsed. At the same time, Ironic is still in the incubation stage, the team officially considers it “beta-sustainable” for the release of Icehouse and is still working on writing user documentation and actively correcting bugs . The goal is to make Ironic available in the release of OpenStack Juno, but this goal can be expanded. As for maturity, this is a project that needs to be monitored and started to be viewed inside the laboratory, but this is definitely not an industrial level project. In general, I personally am enthusiastic about this project and how it will affect service providers.
OpenStack is developing fast and will continue to do so. Both the OpenStack community and the vendors that are players in this segment are working to make it easier for customers to use all the key features, but there are still gaps.
One of the most significant problems is finding reference architectures that match your use case. If you attend any Summit, you will become a member of fantastic meetings, but the bottom line will be the question: “Which architecture should I choose?”
Vendors contribute a lot of code by trying to make OpenStack work with their solutions, but unfortunately, the gold standard, which service providers could use, seems to be missing. At this point, the most common architectures seem to use Ceph for data storage, KVM as a hypervisor / compute node, while the standard network does not exist.
Most of the services within OpenStack today can be protected by HA. Please note that I used the word "most." Many service providers today have customers using old or "lazy" applications , to ensure that HA requires a fundamental infrastructure. The OpenStack platform currently does not provide a ready-made method for providing HA to the entire infrastructure; this was not the goal of its design. To be more concise, OpenStack today does not provide HA for running Nova compute nodes: if the compute nodes themselves fail, then their VMs will not automatically switch to other nodes. OpenStack uses the same approach as Netflix , relying on the fact that developers embed HA into their applications. An application that actually runs on the cloud must be able to withstand any infrastructure failure.
The beauty of technology is that all problems can be solved. If the client requires HA, then it can use another hypervisor, which by default provides HA, for example VMWare , which supports such cool functionality as DRS. Customers who want to continue working with KVM can use, for example, Nagios or Zabbix to monitor the operation of these devices and even automatically restart services.
This issue is discussed in more detail in the blog of my colleague Dmitry Novakovsky about the missing functionality in OpenStack .
Who needs billing? Just kidding As mentioned above, OpenStack is today introducing the Ceilometer project, which monitors the resources used. One of the existing difficulties is that many service providers use their own billing systems and often these are completely individual solutions. In all likelihood, a large community will not take the risk and create some kind of official billing system, so customers should work best with a vendor who wants to integrate with their existing accounting systems.
Service providers operate in one of the most difficult verticals due to the heavy competition. From time to time there are major technological advances that allow businesses to become more dynamic and efficient. OpenStack seems to be the best wave to ride in the future.
Summarizing, we can identify several key principles on which the service provider should focus.
1. Avoid binding to the vendor.
2. Actively apply automation and orchestration.
3. Do not try to deploy the platform yourself, this is a big headache, as a result of which you will get a FrankenStack.
4. Collaborate with a vendor impartial to hardware and software to help you create a solution that meets your needs.
5. Be bold and deploy OpenStack!
Original article in English .
At the last few jobs, I dealt with service providers (service providers of communication / managed services) from Iceland to Tokyo, and they all know that the unconditional leader ("800-pound gorilla") - the public cloud - follows their soul. For a while, they all tried to “pretend to be dead”, but the “gorilla” didn’t care and she continued to run in their direction. During all my trips, I did not doubt one thing: service providers must recognize that something needs to be drastically changed. How can they come to this?
')
Author photo : Ryan Poplin (Ryan Poplin)
Part of my job today is visiting customers to tell them what the OpenStack platform is, what its capabilities are, and whether they can integrate it with their infrastructure. One thing is clear: in order to get involved in the fight against public cloud vendors, the service provider needs to revise and refine its cloud service offerings, shifting the focus to software-defined technologies and automation.
If you look at the public cloud ecosystem, we will see that one of the most serious competitive advantages of the platform are the opportunities for automation. Unfortunately, many service providers today use old hardware and software infrastructure. I recently met with several service providers operating on outdated infrastructure, who, sadly, believe that automation is based on the speed with which their engineers are able to rotate in their chairs. To compete with large public clouds in today's market, service providers are exploring infrastructures such as OpenStack to regain the proper architectural foundation.
Do-it-yourself approach when working with OpenStack
From time to time I came across quite sophisticated service providers who built their own clouds based on OpenStack. The conversation with them was about the following:
Me: It's great that you are working on the OpenStack platform. How are things going with her?
They: This is a nightmare! We spent weeks trying to figure out how to set everything up, and our engineers have to look for answers through the IRC chat and on the forums!
I: Wow!
I believe that many of you are the owner or tenant of your house, which requires basic care and maintenance. I am sure that most of you are not mechanical engineers or designers and have no idea how everything is assembled and working in your house. This is not required of us.
As for OpenStack, then you can draw an analogy with the house. OpenStack is based on many open source, complex projects that are linked through complex APIs that even the most experienced infrastructure support engineers are fighting. From a financial point of view, the choice of this path at the initial stage is likely to have a serious impact on revenues due to unmet business goals and failure to meet deadlines. With the do-it-yourself approach, a lot of people start working with OpenStack and, as a rule, fail, which leaves a very unpleasant aftertaste.
The main business objective of any service provider is to help design and ensure reliable hosting of customer applications. The key to success with OpenStack is to bring in a vendor who has gathered all the necessary code snippets and will provide the service provider with the enterprise level support he needs to run the business. Please, entrust technical support and packaging OpenStack proven vendor.
What gives OpenStack
Today, OpenStack provides a framework by which customers can simplify infrastructures built on heterogeneous technologies by abstraction and combining various software interfaces into one common infrastructure or one API. The most important thing is to increase the efficiency of the data processing center (DPC).
From a network perspective, currently, OpenStack provides ways to integrate with such well-known devices as F5 Big-IP, Cisco Nexus, Citrix Netscaler, and Arista switches (integration with more devices is expected). As for storage, everything from EMC, NetApp, Coraid to Nexenta is integrated with OpenStack . Regarding hypervisors, you can choose from options such as VMWare, KVM, Xen, and HyperV . The service provider can use an infrastructure-independent approach to the data center and allow OpenStack to solve all complex tasks.
According to a user survey at the OpenStack summit in Atlanta, the number one business incentive for using OpenStack is the ability to avoid binding to a single vendor platform. Service providers rely on work with partners in the production of hardware and software (software) that do not point at each other with a finger when solving urgent tasks. Service providers also need to be able to establish strong strategic relationships that will enable them to activate the development plans of products of a particular vendor. If such a relationship is impossible, the service provider is extremely difficult to succeed. OpenStack gives service providers the flexibility that will allow them to get rid of vendors at any time and decide which combination of hardware and software will work in the best way for them and their customers.
Interesting projects for service providers
OpenStack includes about a dozen projects, but outside the kernel, some of the projects may be of more interest to service providers than others. For example:
Heat
In the past, I worked at Carpathia Hosting , a company offering cloud services for businesses. Around 2009, I was working at a startup that provided VM lifecycle management solutions and features similar to those offered by the OpenStack Heat project. In fact, I needed a way to describe my data center through a conceptual project (blueprint) or code that I could save. Then I wanted to have the operational ability to programmatically instantiate new data center blocks from this blueprint. In other words, this startup provided a tool that allowed me to build a Data Center Class, after which I could instantiate new Objects. Very cool! Heat works the same way. This is a way to orchestrate your OpenStack environment with patterns compatible with the AWS Cloudformation service. I highly recommend using the Heat template every time you deploy OpenStack to achieve a high level of automation. You can find a good guide to Heat here .
Ceilometer
All service providers need the ability to determine the amount of resources consumed and the period of their consumption. As mentioned above, if you use an environment that does not depend on hardware, as well as incompatible types of networks and data warehouses, you need a single, unified method of tracking used resources to simplify monitoring and management. A ceilometer is an OpenStack project used by service providers to provide measurement data, which can then be integrated into the billing system. More information can be found in the documentation .
Ironic
Many service providers use different (often complex and headache) ways to automate the builds of their “clean” servers, but I’m now developing an Ironic project in OpenStack, which will give them this opportunity using a single API. Some companies, such as Rackspace, have announced their intention to submit their own version of Ironic called OnMetal. The value of this project is more than just a single API; service providers will be able to take advantage of all the features of OpenStack, including measurements, orchestration, block data storage, etc., on “clean” servers.
Ironic originated from the Nova Bare Metal project, which was then collapsed. At the same time, Ironic is still in the incubation stage, the team officially considers it “beta-sustainable” for the release of Icehouse and is still working on writing user documentation and actively correcting bugs . The goal is to make Ironic available in the release of OpenStack Juno, but this goal can be expanded. As for maturity, this is a project that needs to be monitored and started to be viewed inside the laboratory, but this is definitely not an industrial level project. In general, I personally am enthusiastic about this project and how it will affect service providers.
What is missing OpenStack?
OpenStack is developing fast and will continue to do so. Both the OpenStack community and the vendors that are players in this segment are working to make it easier for customers to use all the key features, but there are still gaps.
Reference architectures
One of the most significant problems is finding reference architectures that match your use case. If you attend any Summit, you will become a member of fantastic meetings, but the bottom line will be the question: “Which architecture should I choose?”
Vendors contribute a lot of code by trying to make OpenStack work with their solutions, but unfortunately, the gold standard, which service providers could use, seems to be missing. At this point, the most common architectures seem to use Ceph for data storage, KVM as a hypervisor / compute node, while the standard network does not exist.
High Availability (HA)
Most of the services within OpenStack today can be protected by HA. Please note that I used the word "most." Many service providers today have customers using old or "lazy" applications , to ensure that HA requires a fundamental infrastructure. The OpenStack platform currently does not provide a ready-made method for providing HA to the entire infrastructure; this was not the goal of its design. To be more concise, OpenStack today does not provide HA for running Nova compute nodes: if the compute nodes themselves fail, then their VMs will not automatically switch to other nodes. OpenStack uses the same approach as Netflix , relying on the fact that developers embed HA into their applications. An application that actually runs on the cloud must be able to withstand any infrastructure failure.
The beauty of technology is that all problems can be solved. If the client requires HA, then it can use another hypervisor, which by default provides HA, for example VMWare , which supports such cool functionality as DRS. Customers who want to continue working with KVM can use, for example, Nagios or Zabbix to monitor the operation of these devices and even automatically restart services.
This issue is discussed in more detail in the blog of my colleague Dmitry Novakovsky about the missing functionality in OpenStack .
Billing
Who needs billing? Just kidding As mentioned above, OpenStack is today introducing the Ceilometer project, which monitors the resources used. One of the existing difficulties is that many service providers use their own billing systems and often these are completely individual solutions. In all likelihood, a large community will not take the risk and create some kind of official billing system, so customers should work best with a vendor who wants to integrate with their existing accounting systems.
Service providers, make it a reality!
Service providers operate in one of the most difficult verticals due to the heavy competition. From time to time there are major technological advances that allow businesses to become more dynamic and efficient. OpenStack seems to be the best wave to ride in the future.
Summarizing, we can identify several key principles on which the service provider should focus.
1. Avoid binding to the vendor.
2. Actively apply automation and orchestration.
3. Do not try to deploy the platform yourself, this is a big headache, as a result of which you will get a FrankenStack.
4. Collaborate with a vendor impartial to hardware and software to help you create a solution that meets your needs.
5. Be bold and deploy OpenStack!
Original article in English .
Source: https://habr.com/ru/post/241341/
All Articles