da Agency

Object storage benefits, myths and options

Object storage is a relatively new option for data storage, optimized for general binary or unstructured data, often multimedia. It has gained a lot of importance in the last few years due to the exponential growth of audio, video and images on the web, and thanks to the huge growth of mobility and social networks.
When developers create new apps, they must decide where and how to store data. Structured data (such as name, date, ID, and so on) will still be stored in regular SQL or NoSQL databases.

Images and other binary data that pass through the app will have a better home with object storage, thanks to the following benefits:

Ease of use. Each object gets a unique ID and a HTTP URL that can be publicly accessible. Data read and write operations are very simple and may be performed directly by user’s browser, via representational stat transfer (REST), without having to go through the control of the server app. The app is released from the rigid structure of database tables and file system hierarchy.
Scalability. Unlike classical storage using files and tables, the infrastructure to store objects doesn’t grow in complexity when data grows. Object storage can grow quickly, without limits.
Agility. File systems and databases are complex and require constant care by the sysadmin or database administrator. Thanks to the simplicity of objects, the developer or app owner doesn’t have to depend on these professionals, which eliminates bottlenecks in the app’s evolution. A developer has more freedom to change an app without the help or blessing of the infrastructure team. This agility aspect is what makes object storage so attractive for modern apps.

 
Myths
Object Storage is not a substitute for older storage methods such as file systems or databases. Rather, it complements them with new features.
There are also inaccurate comparisons between object storage and block storage. These are very different things that solve different problems. Objects are used by programmers at the application level, while block storage is a concern of the infrastructure architect. There is no relation between the two. To compare object and block storage is like comparing cars and tires.
Other uses
Object storage is being used in place of physical tapes and libraries in backup solutions. Maintaining the physical integrity of tapes and robots and transporting them to other locations requires a lot of logistical work.
It is precisely the elimination of these logistics that make object storage-based backup so attractive. You don’t even have to change your backup solution. Object storage can be easily integrated and plugged to what you already have.
Object storage with IBM
IBM Cloud Object Storage focuses on hybrid agility, which means you can have your objects in your own data center, protected by your own firewall, in the public cloud or a mix of both.
In the public cloud, object storage that uses S3 and Swift protocols can be activated in the IBM Bluemix catalog.
Behind the firewall in one’s own data center, there are software options that can be used with an organization’s own, low-cost hardware. There are also integrated options with high-performance hardware.
It also enables transparent hybrid architectures to help organizations find the best cost and benefit balance between their own data centers and public or private clouds.
Final considerations
Here’s a short list of takeaways about object storage:

It does not replace more traditional methods of storage, but complements them with a lot of agility.
It can be used to simplify and reduce the cost of existing and new backup solutions.
IBM Cloud Object Storage helps organizations have consistently integrated data in their own data centers, the public cloud or both.

Visit the Bluemix Catalog to learn more about IBM Cloud Object Storage and use the promotional code COSFREE to start storing objects right now, at no cost, up to 25 GB per month.
Shutterfly has nearly 150 Petabytes of images within its site. Hear how they use IBM Cloud Object Storage to manage—and continue to grow—live at IBM InterConnect.
The post Object storage benefits, myths and options appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

Mirantis and Harmonic bring cloud-native media processing to OpenStack

The post Mirantis and Harmonic bring cloud-native media processing to OpenStack appeared first on Mirantis | Pure Play Open Cloud.
VOS™ Cloud Becomes World’s First Media Processing Solution Available for Live and VOD Production on an OpenStack Cloud

SAN JOSE and SUNNYVALE, Calif. — Feb. 1, 2017 — Harmonic (NASDAQ: HLIT), the worldwide leader in video delivery infrastructure, and Mirantis, a pure-play open cloud company, today announced a new partnership that is providing media content and service providers with access to the industry’s first media processing solution for live and VOD production on OpenStack. Mirantis and Harmonic have ensured interoperability of Harmonic’s VOS™ Cloud media processing solution and Mirantis’ cloud platform, allowing customers to manage the entire media production and delivery workflow for broadcast and over-the-top (OTT) applications on standard IT hardware in a scalable cloud environment. The joint solution has successfully been deployed by a leading North American service provider, and is in numerous trials with other service providers worldwide.

“Harmonic and Mirantis share a common belief: that video content production and delivery should be simple, agile and efficient,” said Boris Renski, CMO and co-founder of Mirantis. “Our work with Harmonic expands the scope of media processing in the cloud. Service providers can use the joint solution to launch new broadcast and OTT services with amazing video quality and a short time to market.”

Mirantis Cloud Platform (MCP) is a cloud-native infrastructure software based on open standards such as OpenStack, Kubernetes and Docker. It leverages architectural principles developed by Google to make it simple and cost effective to manage. Mirantis delivers MCP to enterprise customers though a build-operate-transfer model, minimizing the lock-in and ballooning costs that are typical of traditional cloud delivery approaches. MCP is currently in use by a limited number of beta customers and will become generally available by the end of Q1 2017.

The comprehensive VOS Cloud software solution, embedded with a unified code structure combining the expertise of Harmonic and recently acquired Thomson Video Networks, makes configuration, deployment and orchestration of powerful media processing and delivery workflows easy via an automated video and cloud formation technology using standard OpenStack deployment templates. Featuring capabilities such as live video encoding with time-shift TV services, as well as VOD and cloud DVR, VOS Cloud software enables service providers to generate instant revenue, without the traditional CAPEX involved with building, maintaining and operating a new headend or data center. Pay-as-you-go pricing allows service providers to realize ROI in the shortest time possible.

“Unleashing the power of VOS Cloud software on the Mirantis Cloud Platform will stimulate monumental change in the industry, allowing video content and service providers to compete on a level that was never possible before, in terms of speed and flexibility,” said Bart Spriester, senior vice president, video products, at Harmonic. “We chose Mirantis as an ecosystem partner because they’re a major player in the OpenStack market and provide a robust set of OpenStack control-plane services that can be used with best-in-class infrastructure.”

Further information about Harmonic and the company’s products is available at www.harmonicinc.com.

# # #

About Mirantis

Mirantis helps top enterprises build and manage private cloud infrastructure using OpenStack and related open source technologies. The company is the top contributor of open source code to the OpenStack project and follows a build-operate-transfer model to deliver its OpenStack distribution and cloud management services, empowering customers to take advantage of open source innovation with no vendor lock-in. To date Mirantis has helped over 200 enterprises build and operate some of the largest OpenStack clouds in the world. Its customers include iconic brands such as AT&T, Comcast, Shenzhen Stock Exchange, eBay, Wells Fargo Bank and Volkswagen. Learn more at www.mirantis.com.

About Harmonic

Harmonic (NASDAQ: HLIT) is the worldwide leader in video delivery infrastructure for emerging television and video services. Harmonic enables customers to produce, deliver and monetize amazing video experiences, with unequalled business agility and operational efficiency, by providing market-leading innovation, high-quality service, and compelling total-cost-of-ownership. More information is available at www.harmonicinc.com.

This press release contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements related to the anticipated capabilities and benefits of Harmonic’s VOS Cloud software product. Our expectations and beliefs regarding our VOS Cloud product may not materialize and are subject to risks and uncertainties, including the possibility that the product may not meet some or all of its anticipated capabilities or provide some or all of its anticipated benefits, such as: a shortened time-to-market launch of new broadcast and OTT service; enabling the generation of instant revenue stream without the traditional CAPEX requirements; and other cost savings and operational benefits expected by customers.

The forward-looking statements contained in this press release are also subject to other risks and uncertainties, such as those more fully described in Harmonic’s filings with the Securities and Exchange Commission, including its Annual Report on Form 10-K for the year ended Dec.31, 2015, its Quarterly Reports on Form 10-Q and its Current Reports on Form 8-K. The forward-looking statements in this press release are based on information available to Harmonic as of the date hereof, and Harmonic disclaims any obligation to update any forward-looking statements.

EDITOR’S NOTE – Product and company names used herein are trademarks or registered trademarks of their respective owners.

CONTACTS:

Sarah Kavanagh
Senior Public Relations Manager
Harmonic
+1.408.490.6607
sarah.kavanagh@harmonicinc.com
Blair King
Director, Investor Relations
Harmonic
+1.408.490.6172
blair.king@harmonicinc.com
Sarah Bennett
Public Relations Manager
Mirantis
sbennett@mirantis.com

The post Mirantis and Harmonic bring cloud-native media processing to OpenStack appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

da Agency

How streaming video unites direct-sales teams

There’s been a lot of buzz around streaming video&8217;s potential to transform the way that corporate organizations — especially those with teams scattered around the world — communicate, collaborate and sell.
But what about companies with a direct-sales model? Is there a role for streaming video to play in helping groups of independent sales representatives improve their game and feel like they are all part of one team?
Jennifer Thompson, an independent distributor for SeneGence International, can attest that there is. Since becoming the leader of an international team of 400 independent distributors for the cosmetics and skincare company several months ago, Thompson has been using live streaming video to conduct biweekly training sessions. 
“We discuss product knowledge and share marketing, advertising and social media tips,” she says. “It&8217;s an effective platform for sharing best practices and creating an experience that feels like everyone is working in a real company setting.&8221;
A marketing and communications veteran, Thompson says she immediately recognized the value of using video to virtually and cost-effectively bring together direct-sales team members located across the United States, United Kingdom, Canada and Australia. She uses live video to train and onboard new employees in a way that makes everyone feel involved in the organization. 
Virtual training and collaboration
Thompson develops all the training materials she uses, with the exception of product-related information provided by SeneGence. She also frequently conducts spur-of-the-moment training sessions on specific topics for her team, who communicate almost exclusively through a closed group on Facebook.
“I monitor the discussions in our group in real time. If I see an issue that&8217;s generating a lot of questions from, or conversation within, our group, I will offer to do a 15-minute live training on the spot to talk through it,&8221; she says. “I also receive direct messages from reps asking me to conduct quick training sessions on specific topics.&8221;
Thompson adds that this direct access to leadership for team members is a major benefit of using live video. Though there was a learning curve when she first introduced the idea of live video training, her sessions are now well-attended, and team members actually request these sessions.
Seamlessly bringing new employees on board
Thompson says that streaming video has quickly become her go-to tool for onboarding new SeneGence distributors as well. Video helps the new members feel more connected to the rest of the team and more comfortable asking questions, a substantial improvement from Thompson&8217;s own onboarding experience, which took place via text messages.
Live video “has really been a game changer for many of the women on my team,” she says. “They are more comfortable sharing information, initiating discussions and collaborating. That&8217;s been an incredible takeaway for me as their team leader, and it&8217;s an incentive for me to keep expanding our group&8217;s use of video.&8221;
Learn more about using video for direct-sales training at IBM Cloud Video.
But what about companies with a direct-sales model? Is there a role for streaming video to play in helping groups of independent sales representatives improve their game and feel like they are all part of one team?
Jennifer Thompson, an independent distributor for SeneGence International, can attest that there is. Since becoming the leader of an international team of 400 independent distributors for the cosmetics and skincare company several months ago, Thompson has been using live streaming video to conduct biweekly training sessions. 
“We discuss product knowledge and share marketing, advertising and social media tips,&8221; she says. “It&8217;s an effective platform for sharing best practices and creating an experience that feels like everyone is working in a real company setting.&8221;
A marketing and communications veteran, Thompson says she immediately recognized the value of using video to virtually and cost-effectively bring together direct-sales team members located across the United States, United Kingdom, Canada and Australia. She uses live video to train and onboard new employees in a way that makes everyone feel involved in the organization. 
Virtual training and collaboration
Thompson develops all the training materials she uses, with the exception of product-related information provided by SeneGence. She also frequently conducts spur-of-the-moment training sessions on specific topics for her team, who communicate almost exclusively through a closed group on Facebook.
“I monitor the discussions in our group in real time. If I see an issue that&8217;s generating a lot of questions from, or conversation within, our group, I will offer to do a 15-minute live training on the spot to talk through it,&8221; she says. “I also receive direct messages from reps asking me to conduct quick training sessions on specific topics.&8221;
Thompson adds that this direct access to leadership for team members is a major benefit of using live video. Though there was a learning curve when she first introduced the idea of live video training, her sessions are now well-attended, and team members actually request these sessions.
Seamlessly bringing new employees on board
Thompson says that streaming video has quickly become her go-to tool for onboarding new SeneGence distributors as well. Video helps the new members feel more connected to the rest of the team and more comfortable asking questions, a substantial improvement from Thompson&8217;s own onboarding experience, which took place via text messages.
Live video &8220;has really been a game changer for many of the women on my team,” she says. “They are more comfortable sharing information, initiating discussions and collaborating. That&8217;s been an incredible takeaway for me as their team leader, and it&8217;s an incentive for me to keep expanding our group&8217;s use of video.&8221;
Learn more about using video for direct-sales training at IBM Cloud Video.
The post How streaming video unites direct-sales teams appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

5 must-see WebSphere sessions at IBM InterConnect 2017

WebSphere users, gather round. By now you surely have heard that IBM InterConnect 2017 will be jam-packed with thousands of exciting sessions, labs, roundtables, meetings and events. As you make your plans, check out my cheat sheet of the top five must-see WebSphere sessions.
1. Session #4938: The total economic impact of migrating from open source application servers to IBM WebSphere Liberty
There are many advantages to open source application servers, which is why they are so popular with businesses. But there may also be some hidden costs associated with running your applications on open source. Don’t you want to know what they are?
In this session, Forrester Consulting will take you through the results of a recent Total Economic Impact (TEI) study analyzing the potential return on investment enterprises may experience by migrating from open source Java EE application servers to WebSphere Liberty. Highlights include:

An increase return on investment (ROI) by 122 percent.
Save $350,000 dollars annually within three years by running applications on fewer servers.
Save 3,600 hours of administration time annually.
Increase application development productivity by 12 percent.

2. Session #3217: Installing and deploying WebSphere at scale in the real world: an expert panel
Ever wonder how you would install and deploy WebSphere at large scale in enterprise environments? If so, join us to learn from real-world experts about deploying WebSphere at scale in the enterprise. You’ll also learn about topics such as creating master images for massive deployments, swinging profiles and automation technologies like Chef.
3. Session #2541: WebSphere Application Server V9 update: on-premises and in the cloud
Cloud economics are changing how businesses create, host and manage their applications. But organizations still need to integrate and manage those applications alongside existing software. This is true regardless of whether hosting is on private or public cloud environments. WebSphere and WebSphere Liberty have evolved with cloud economics to provide DevOps capabilities for continuous delivery of cloud-native applications that adopt microservices principles. This comes in addition to the traditional support of large-scale and highly-available enterprise applications. Come to this session to learn from our experts about the latest updates to WebSphere.
4. Session #1652: Understanding competitive TCO for  WebSphere Application Server deployments on-premises and in the cloud
You make a lot of runtime decisions for your Java applications. You can choose to run them across any combination of private, public or hybrid cloud environments. Do you run them in a virtual machine or in Docker? Do you use platform as a service (PaaS) on the IBM Cloud or a third-party cloud? How do you decide? Come to this session to learn about the tools that can help, such as our WebSphere total cost of ownership calculator.
5. Session #1833: A panel of WAS Liberty users answer your questions
Do you have a question about WebSphere Liberty? Here’s the place to ask it. In this panel discussion, customers from different industries will talk about their journeys to a modern and flexible application infrastructure using the WebSphere Liberty runtime on a variety of cloud and hybrid platforms.
These are just a few highlights of the many exciting sessions at the conference. You can’t afford to miss this world-class opportunity to train, network and learn about the future of cloud and cognitive computing. If you’re still not signed up for InterConnect 2017, be sure to register today.
The post 5 must-see WebSphere sessions at IBM InterConnect 2017 appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

5 Must-See WebSphere Sessions at IBM InterConnect 2017

WebSphere users, gather round. By now you surely have heard that IBM InterConnect 2017 will be jam-packed with thousands of exciting sessions, labs, roundtables, meetings and events. As you make your plans, check out my cheat sheet of the top five must-see WebSphere sessions.
1. Session #4938: The total economic impact of migrating from open source application servers to IBM WebSphere Liberty
There are many advantages to open source application servers, which is why they are so popular with businesses. But there may also be some hidden costs associated with running your applications on open source. Don’t you want to know what they are?
In this session, Forrester Consulting will take you through the results of a recent Total Economic Impact (TEI) study analyzing the potential return on investment enterprises may experience by migrating from open source Java EE application servers to WebSphere Liberty. Highlights include:

An increase return on investment (ROI) by 122 percent.
Save $350,000 dollars annually within three years by running applications on fewer servers.
Save 3,600 hours of administration time annually.
Increase application development productivity by 12 percent.

2. Session #3217: Installing and deploying WebSphere at scale in the real world: an expert panel
Ever wonder how you would install and deploy WebSphere at large scale in enterprise environments? If so, join us to learn from real-world experts about deploying WebSphere at scale in the enterprise. You’ll also learn about topics such as creating master images for massive deployments, swinging profiles and automation technologies like Chef.
3. Session #2541: WebSphere Application Server V9 update: on-premises and in the cloud
Cloud economics are changing how businesses create, host and manage their applications. But organizations still need to integrate and manage those applications alongside existing software. This is true regardless of whether hosting is on private or public cloud environments. WebSphere and WebSphere Liberty have evolved with cloud economics to provide DevOps capabilities for continuous delivery of cloud-native applications that adopt microservices principles. This comes in addition to the traditional support of large-scale and highly-available enterprise applications. Come to this session to learn from our experts about the latest updates to WebSphere.
4. Session #1652: Understanding competitive TCO for  WebSphere Application Server deployments on-premises and in the cloud
You make a lot of runtime decisions for your Java applications. You can choose to run them across any combination of private, public or hybrid cloud environments. Do you run them in a virtual machine or in Docker? Do you use platform as a service (PaaS) on the IBM Cloud or a third-party cloud? How do you decide? Come to this session to learn about the tools that can help, such as our WebSphere total cost of ownership calculator.
5. Session #1833: A panel of WAS Liberty users answer your questions
Do you have a question about WebSphere Liberty? Here’s the place to ask it. In this panel discussion, customers from different industries will talk about their journeys to a modern and flexible application infrastructure using the WebSphere Liberty runtime on a variety of cloud and hybrid platforms.
These are just a few highlights of the many exciting sessions at the conference. You can’t afford to miss this world-class opportunity to train, network and learn about the future of cloud and cognitive computing. If you’re still not signed up for InterConnect 2017, be sure to register today.
The post 5 Must-See WebSphere Sessions at IBM InterConnect 2017 appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

RDO at FOSDEM this week

This week, RDO will have a presence at the FOSDEM conference, in Brussels, Belgium.

First, on Friday, there will be a number of RDO-related presentations at the CentOS Dojo which will be held at the Marriott Grand Place. Registration is free but there are a very limited number of spaces available, so register soon to secure your spot.

On Saturday and Sunday, RDO will be sharing space with CentOS in the stands area, along with dozens of other Free/Open Source organizations, projects, and foundations. We’ll also be helping to staff the OpenStack stand.

If you’re going to be at FOSDEM, and want to help us staff the OpenStack stand, have a look at the schedule and sign up.
Quelle: RDO

da Agency

Remove the obstacles delaying your large-scale cloud adoption

Many CIOs recognize the value of cloud, but there can be significant barriers to large-scale cloud adoption.
Company leaders find their organizations unprepared to migrate the optimal workloads to cloud for early success, facing security challenges they didn’t anticipate, making IT decisions that don’t make financial sense for the business, or taking a minimal or ad hoc approach to governance and organizational issues.
All these scenarios can unintentionally create sub-optimal cloud environments. Organizations looking to avoid or remove such obstacles, and free up IT resources to reinvest in more strategic projects, can join more than 20,000 thought leaders and industry experts at IBM InterConnect 2017, 19 – 23 March, in Las Vegas.
At InterConnect, speakers will discuss how organizations can prepare for cloud’s impact and ensure successful implementations. Here’s a sample of some of the featured topics in the cloud managed services area:
Learn how IBM Cloud Migration Services brings end-to-end cloud services to businesses of all sizes
If resource and skill limitations make moving to a hybrid cloud infrastructure a continuing challenge for your organization, learn how specific pre-migration preparation and migration services can ensure a successful move. Get proof from our experts in the field.
Do you know the six questions every CIO should ask about cloud managed services security?
When evaluating a cloud service provider, asking the right security questions is critical in determining if the solution is a good fit. During this breakout session, meet with our cloud security experts to understand why not all cloud providers can deliver adequate security, the six security questions you should ask and what to listen for to assure you have the right coverage.
Calculate your infrastructure savings from implementing IBM Cloud Managed Services in 20 minutes
In 20 minutes, you can get a personalized report of your potential annual savings from implementing IBM Cloud Managed Services based on your unique information. You can even select a unique estimator tool to use for SAP and Oracle landscapes.
How to stop governance and organizational issues from delaying your large-scale cloud adoption plans
Industry research and IBM experience indicate that governance and organizational issues continue to be a significant barrier to large-scale cloud adoption. This session addresses how organizations can prepare for cloud&8217;s impact with IBM cloud governance, organization health check and framework services to shore up capability to enable and manage cloud services
Learn more about InterConnect and register. You can use the preview tool to review all sessions, based on your area of interest.
The post Remove the obstacles delaying your large-scale cloud adoption appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

Remove the obstacles delaying your large-scale cloud adoption

Many CIOs recognize the value of cloud, but there can be significant barriers to large-scale cloud adoption.
Company leaders find their organizations unprepared to migrate the optimal workloads to cloud for early success, facing security challenges they didn’t anticipate, making IT decisions that don’t make financial sense for the business, or taking a minimal or ad hoc approach to governance and organizational issues.
All these scenarios can unintentionally create sub-optimal cloud environments. Organizations looking to avoid or remove such obstacles, and free up IT resources to reinvest in more strategic projects, can join more than 20,000 thought leaders and industry experts at IBM InterConnect 2017, 19 – 23 March, in Las Vegas.
At InterConnect, speakers will discuss how organizations can prepare for cloud’s impact and ensure successful implementations. Here’s a sample of some of the featured topics in the cloud managed services area:
Learn how IBM Cloud Migration Services brings end-to-end cloud services to businesses of all sizes
If resource and skill limitations make moving to a hybrid cloud infrastructure a continuing challenge for your organization, learn how specific pre-migration preparation and migration services can ensure a successful move. Get proof from our experts in the field.
Do you know the six questions every CIO should ask about cloud managed services security?
When evaluating a cloud service provider, asking the right security questions is critical in determining if the solution is a good fit. During this breakout session, meet with our cloud security experts to understand why not all cloud providers can deliver adequate security, the six security questions you should ask and what to listen for to assure you have the right coverage.
Calculate your infrastructure savings from implementing IBM Cloud Managed Services in 20 minutes
In 20 minutes, you can get a personalized report of your potential annual savings from implementing IBM Cloud Managed Services based on your unique information. You can even select a unique estimator tool to use for SAP and Oracle landscapes.
How to stop governance and organizational issues from delaying your large-scale cloud adoption plans
Industry research and IBM experience indicate that governance and organizational issues continue to be a significant barrier to large-scale cloud adoption. This session addresses how organizations can prepare for cloud&8217;s impact with IBM cloud governance, organization health check and framework services to shore up capability to enable and manage cloud services
Learn more about InterConnect and register. You can use the preview tool to review all sessions, based on your area of interest.
The post Remove the obstacles delaying your large-scale cloud adoption appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

da Agency

The first and final words on OpenStack availability zones

The post The first and final words on OpenStack availability zones appeared first on Mirantis | Pure Play Open Cloud.
Availability zones are one of the most frequently misunderstood and misused constructs in OpenStack. Each cloud operator has a different idea about what they are and how to use them. What’s more, each OpenStack service implements availability zones differently — if it even implements them at all.
Often, there isn’t even agreement over the basic meaning or purpose of availability zones.
On the one hand, you have the literal interpretation of the words “availability zone”, which would lead us to think of some logical subdivision of resources into failure domains, allowing cloud applications to intelligently deploy in ways to maximize their availability. (We’ll be running with this definition for the purposes of this article.)
On the other hand, the different ways that projects implement availability zones lend themselves to certain ways of using the feature as a result. In other words, because this feature has been implemented in a flexible manner that does not tie us down to one specific concept of an availability zone, there&8217;s a lot of confusion over how to use them.
In this article, we&8217;ll look at the traditional definition of availability zones, insights into and best practices for planning and using them, and even a little bit about non-traditional uses. Finally, we hope to address the question: Are availability zones right for you?
OpenStack availability zone Implementations
One of the things that complicates use of availability zones is that each OpenStack project implements them in their own way (if at all). If you do plan to use availability zones, you should evaluate which OpenStack projects you&8217;re going to use support them, and how that affects your design and deployment of those services.
For the purposes of this article, we will look at three core services with respect to availability zones: #Nova, Cinder, and Neutron. We won&8217;t go into the steps to set up availability zones, but but instead we&8217;ll focus on a few of the key decision points, limitations, and trouble areas with them.
Nova availability zones
Since host aggregates were first introduced in OpenStack Grizzly, I have seen a lot of confusion about availability zones in Nova. Nova tied their availability zone implementation to host aggregates, and because the latter is a feature unique to the Nova project, its implementation of availability zones is also unique.
I have had many people tell me they use availability zones in Nova, convinced they are not using host aggregates. Well, I have news for these people &8212; all* availability zones in Nova are host aggregates (though not all host aggregates are availability zones):
* Exceptions being the default_availability_zone that compute nodes are placed into when not in another user-defined availability zone, and the internal_service_availability_zone where other nova services live
Some of this confusion may come from the nova CLI. People may do a quick search online, see they can create an availability zone with one command, and may not realize that they’re actually creating a host aggregate. Ex:
$ nova aggregate-create <aggregate name> <AZ name>
$ nova aggregate-create HA1 AZ1
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 4  |   HA1   | AZ1               |       | ‘availability_zone=AZ1’|
+—-+———+——————-+——-+————————+
I have seen people get confused with the second argument (the AZ name). This is just a shortcut for setting the availability_zone metadata for a new host aggregate you want to create.
This command is equivalent to creating a host aggregate, and then setting the metadata:
$ nova aggregate-create HA1
+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 7  |   HA1   | –                 |       |          |
+—-+———+——————-+——-+———-+
$ nova aggregate-set-metadata HA1 availability_zone=AZ1
Metadata has been successfully updated for aggregate 7.
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 7  |   HA1   | AZ1               |       | ‘availability_zone=AZ1’|
+—-+———+——————-+——-+————————+
Doing it this way, it’s more apparent that the workflow is the same as any other host aggregate, the only difference is the “magic” metadata key availability_zone which we set to AZ1 (notice we also see AZ1 show up under the Availability Zone column). And now when we add compute nodes to this aggregate, they will be automatically transferred out of the default_availability_zone and into the one we have defined. For example:
Before:
$ nova availability-zone-list
| nova              | available                              |
| |- node-27        |                                        |
| | |- nova-compute | enabled :-) 2016-11-06T05:13:48.000000 |
+——————-+—————————————-+
After:
$ nova availability-zone-list
| AZ1               | available                              |
| |- node-27        |                                        |
| | |- nova-compute | enabled :-) 2016-11-06T05:13:48.000000 |
+——————-+—————————————-+
Note that there is one behavior that sets apart the availability zone host aggregates apart from others. Namely, nova does not allow you to assign the same compute host to multiple aggregates with conflicting availability zone assignments. For example, we can first add compute a node to the previously created host aggregate with availability zone AZ1:
$ nova aggregate-add-host HA1 node-27
Host node-27 has been successfully added for aggregate 7
+—-+——+——————-+———-+————————+
| Id | Name | Availability Zone | Hosts    | Metadata               |
+—-+——+——————-+———-+————————+
| 7  | HA1  | AZ1               | ‘node-27’| ‘availability_zone=AZ1’|
+—-+——+——————-+———-+————————+
Next, we create a new host aggregate for availability zone AZ2:
$ nova aggregate-create HA2

+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 13 |   HA2   | –                 |       |          |
+—-+———+——————-+——-+———-+

$ nova aggregate-set-metadata HA2 availability_zone=AZ2
Metadata has been successfully updated for aggregate 13.
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 13 |   HA2   | AZ2               |       | ‘availability_zone=AZ2’|
+—-+———+——————-+——-+————————+
Now if we try to add the original compute node to this aggregate, we get an error because this aggregate has a conflicting availability zone:
$ nova aggregate-add-host HA2 node-27
ERROR (Conflict): Cannot add host node-27 in aggregate 13: host exists (HTTP 409)
+—-+——+——————-+———-+————————+
| Id | Name | Availability Zone | Hosts    | Metadata               |
+—-+——+——————-+———-+————————+
| 13 | HA2  | AZ2               |          | ‘availability_zone=AZ2’|
+—-+——+——————-+———-+————————+
(Incidentally, it is possible to have multiple host aggregates with the same availability_zone metadata, and add the same compute host to both. However, there are few, if any, good reasons for doing this.)
In contrast, Nova allows you to assign this compute node to another host aggregate with other metadata fields, as long as the availability_zone doesn&8217;t conflict:
You can see this if you first create a third host aggregate:
$ nova aggregate-create HA3
+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 16 |   HA3   | –                 |       |          |
+—-+———+——————-+——-+———-+
Next, tag  the host aggregate for some purpose not related to availability zones (for example, an aggregate to track compute nodes with SSDs):
$ nova aggregate-set-metadata HA3 ssd=True
Metadata has been successfully updated for aggregate 16.
+—-+———+——————-+——-+———–+
| Id | Name    | Availability Zone | Hosts |  Metadata |
+—-+———+——————-+——-+———–+
| 16 |   HA3   | –                 |       | ‘ssd=True’|
+—-+———+——————-+——-+———–+
Adding original node to another aggregate without conflicting availability zone metadata works:
$ nova aggregate-add-host HA3 node-27
Host node-27 has been successfully added for aggregate 16
+—-+——-+——————-+———–+————+
| Id | Name  | Availability Zone | Hosts     |  Metadata  |
+—-+——-+——————-+———–+————+
| 16 | HA3   | –                 | ‘node-27′ | ‘ssd=True’ |
+—-+——-+——————-+———–+————+
(Incidentally, Nova will also happily let you assign the same compute node to another aggregate with ssd=False for metadata, even though that clearly doesn&8217;t make sense. Conflicts are only checked/enforced in the case of the availability_zone metadata.)
Nova configuration also holds parameters relevant to availability zone behavior. In the nova.conf read by your nova-api service, you can set a default availability zone for scheduling, which is used if users do not specify an availability zone in the API call:
[DEFAULT]
default_schedule_zone=AZ1
However, most operators leave this at its default setting (None), because it allows users who don’t care about availability zones to omit it from their API call, and the workload will be scheduled to any availability zone where there is available capacity.
If a user requests an invalid or undefined availability zone, the Nova API will report back with an HTTP 400 error. There is no availability zone fallback option.
Cinder
Creating availability zones in Cinder is accomplished by setting the following configuration parameter in cinder.conf, on the nodes where your cinder-volume service runs:
[DEFAULT]
storage_availability_zone=AZ1
Note that you can only set the availability zone to one value. This is consistent with availability zones in other OpenStack projects that do not allow for the notion of overlapping failure domains or multiple failure domain levels or tiers.
The change takes effect when you restart your cinder-volume services. You can confirm your availability zone assignments as follows:
cinder service-list
+—————+——————-+——+———+——-+
|     Binary    |        Host       | Zone | Status  | State |
+—————+——————-+——+———+——-+
| cinder-volume | hostname1@LVM     |  AZ1 | enabled |   up  |
| cinder-volume | hostname2@LVM     |  AZ2 | enabled |   up  |
If you would like to establish a default availability zone, you can set the this parameter in cinder.conf on the cinder-api nodes:
[DEFAULT]
default_availability_zone=AZ1
This instructs Cinder which availability zone to use if the API call did not specify one. If you don’t, it will use a hardcoded default, nova. In the case of our example, where we&8217;ve set the default availability zone in Nova to AZ1, this would result in a failure. This also means that unlike Nova, users do not have the flexibility of omitting availability zone information and expecting that Cinder will select any available backend with spare capacity in any availability zone.
Therefore, you have a choice with this parameter. You can set it to one of your availability zones so API calls without availability zone information don’t fail, but causing a potential situation of uneven storage allocation across your availability zones. Or, you can not set this parameter, and accept that user API calls that forget or omit availability zone info will fail.
Another option is to set the default to a non-existent availability zone you-must-specify-an-AZ or something similar, so when the call fails due to the non-existant availability zone, this information will be included in the error message sent back to the client.
Your storage backends, storage drivers, and storage architecture may also affect how you set up your availability zones. If we are using the reference Cinder LVM ISCSI Driver deployed on commodity hardware, and that hardware fits the same availability zone criteria of our computes, then we could setup availability zones to match what we have defined in Nova. We could also do the same if we had a third party storage appliance in each availability zone, e.g.:
|     Binary    |           Host          | Zone | Status  | State |
| cinder-volume | hostname1@StorageArray1 |  AZ1 | enabled |   up  |
| cinder-volume | hostname2@StorageArray2 |  AZ2 | enabled |   up  |
(Note: Notice that the hostnames (hostname1 and hostname2) are still different in this example. The cinder multi-backend feature allows us to configure multiple storage backends in the same cinder.conf (for the same cinder-volume service), but Cinder availability zones can only be defined per cinder-volume service, and not per-backend per-cinder-volume service. In other words, if you define multiple backends in one cinder.conf, they will all inherit the same availability zone.)
However, in many cases if you’re using a third party storage appliance, then these systems usually have their own built-in redundancy that exist outside of OpenStack notions of availability zones. Similarly if you use a distributed storage solution like Ceph, then availability zones have little or no meaning in this context. In this case, you can forgo Cinder availability zones.
The one issue in doing this, however, is that any availability zones you defined for Nova won’t match. This can cause problems when Nova makes API calls to Cinder &#8211; for example, when performing a Boot from Volume API call through Nova. If Nova decided to provision your VM in AZ1, it will tell Cinder to provision a boot volume in AZ1, but Cinder doesn’t know anything about AZ1, so this API call will fail. To prevent this from happening, we need to set the following parameter in cinder.conf on your nodes running cinder-api:
[DEFAULT]
allow_availability_zone_fallback=True
This parameter prevents the API call from failing, because if the requested availability zone does not exist, Cinder will fallback to another availability zone (whichever you defined in default_availability_zone parameter, or in storage_availability_zone if the default is not set). The hardcoded default storage_availability_zone is nova, so the fallback availability zone should match the default availability zone for your cinder-volume services, and everything should work.
The easiest way to solve the problem, however is to remove the AvailabilityZoneFilter from your filter list in cinder.conf on nodes running cinder-scheduler. This makes the scheduler ignore any availability zone information passed to it altogether, which may also be helpful in case of any availability zone configuration mismatch.
Neutron
Availability zone support was added to Neutron in the Mitaka release. Availability zones can be set for DHCP and L3 agents in their respective configuration files:
[AGENT]
Availability_zone = AZ1
Restart the agents, and confirm availability zone settings as follows:
neutron agent-show <agent-id>
+———————+————+
| Field               | Value      |
+———————+————+
| availability_zone   | AZ1        |
…
If you would like to establish a default availability zone, you can set the this parameter in neutron.conf on neutron-server nodes:
[DEFAULT]
default_availability_zones=AZ1,AZ2
This parameters tells Neutron which availability zones to use if the API call did not specify any. Unlike Cinder, you can specify multiple availability zones, and leaving it undefined places no constraints in scheduling, as there are no hard coded defaults. If you have users making API calls that do not care about the availability zone, then you can enumerate all your availability zones for this parameter, or simply leave it undefined &8211; both would yield the same result.
Additionally, when users do specify an availability zone, such requests are fulfilled as a “best effort” in Neutron. In other words, there is no need for an availability zone fallback parameter, because your API call still execute even if your availability zone hint can’t be satisfied.
Another important distinction that sets Neutron aside from Nova and Cinder is that it implements availability zones as scheduler hints, meaning that on the client side you can repeat this option to chain together multiple availability zone specifications in the event that more than one availability zone would satisfy your availability criteria. For example:
$ neutron net-create –availability-zone-hint AZ1 –availability-zone-hint AZ2 new_network
As with Cinder, the Neutron plugins and backends you’re using deserve attention, as the support or need for availability zones may be different depending on their implementation. For example, if you’re using a reference Neutron deployment with the ML2 plugin and with DHCP and L3 agents deployed to commodity hardware, you can likely place these agents consistently according to the same availability zone criteria used for your computes.
Whereas in contrast, other alternatives such as the Contrail plugin for Neutron do not support availability zones. Or if you are using Neutron DVR for example, then availability zones have limited significance for Layer 3 Neutron.
OpenStack Project availability zone Comparison Summary
Before we move on, it&8217;s helpful to review how each project handles availability zones.

Nova
Cinder
Neutron

Default availability zone scheduling
Can set to one availability zone or None
Can set one availability zone; cannot set None
Can set to any list of availability zones or none

Availability zone fallback
None supported
Supported through configuration
N/A; scheduling to availability zones done on a best effort basis

Availability zone definition restrictions
No more than #1 availability zone per nova-compute
No more than 1 availability zone per cinder-volume
No more than 1 availability zone per neutron agent

Availability zone client restrictions
Can specify one availability zone or none
Can specify one availability zone or none
Can specify an arbitrary number of availability zones

Availability zones typically used when you have &#8230;
Commodity HW for computes, libvirt driver
Commodity HW for storage, LVM iSCSI driver
Commodity HW for neutron agents, ML2 plugin

Availability zones not typically used when you have&8230;
Third party hypervisor drivers that manage their own HA for VMs (DRS for VCenter)
Third party drivers, backends, etc. that manage their own HA
Third party plugins, backends, etc. that manage their own HA

Best Practices for availability zones
Now let&8217;s talk about how to best make use of availability zones.
What should my availability zones represent?
The first thing you should do as a cloud operator is to nail down your own accepted definition of an availability zone and how you will use them, and remain consistent. You don’t want to end up in a situation where availability zones are taking on more than one meaning in the same cloud. For example:
Fred’s AZ            | Example of AZ used to perform tenant workload isolation
VMWare cluster 1 AZ | Example of AZ used to select a specific hypervisor type
Power source 1 AZ   | Example of AZ used to select a specific failure domain
Rack 1 AZ           | Example of AZ used to select a specific failure domain
Such a set of definitions would be a source of inconsistency and confusion in your cloud. It’s usually better to keep things simple with one availability zone definition, and use OpenStack features such as Nova Flavors or Nova/Cinder boot hints to achieve other requirements for multi-tenancy isolation, ability to select between different hypervisor options and other features, and so on.
Note that OpenStack currently does not support the concept of multiple failure domain levels/tiers. Even though we may have multiple ways to define failure domains (e.g., by power circuit, rack, room, etc), we must pick a single convention.
For the purposes of this article, we will discuss availability zones in the context of failure domains. However, we will cover one other use for availability zones in the third section.
How many availability zones do I need?
One question that customers frequently get hung up on is how many availability zones they should create. This can be tricky because the setup and management of availability zones involves stakeholders at every layer of the solution stack, from tenant applications to cloud operators, down to data center design and planning.

A good place to start is your cloud application requirements: How many failure domains are they designed to work with (i.e. redundancy factor)? The likely answer is two (primary + backup), three (for example, for a database or other quorum-based system), or one (for example, a legacy app with single points of failure). Therefore, the vast majority of clouds will have either 2, 3, or 1 availability zone.
Also keep in mind that as a general design principle, you want to minimize the number of availability zones in your environment, because the side effect of availability zone proliferation is that you are dividing your capacity into more resource islands. The resource utilization in each island may not be equal, and now you have an operational burden to track and maintain capacity in each island/availability zone. Also, if you have a lot of availability zones (more than the redundancy factor of tenant applications), tenants are left to guess which availability zones to use and which have available capacity.
How do I organize my availability zones?
The value proposition of availability zones is that tenants are able to achieve a higher level of availability in their applications. In order to make good on that proposition, we need to design our availability zones in ways that mitigate single points of failure.             
For example, if our resources are split between two power sources in the data center, then we may decide to define two resource pools (availability zones) according to their connected power source:
Or, if we only have one TOR switch in our racks, then we may decide to define availability zones by rack. However, here we can run into problems if we make each rack its own availability zone, as this will not scale from a capacity management perspective for more than 2-3 racks/availability zones (because of the &#8220;resource island&#8221; problem). In this case, you might consider dividing/arranging your total rack count into into 2 or 3 logical groupings that correlate to your defined availability zones:
We may also find situations where we have redundant TOR switch pairs in our racks, power source diversity to each rack, and lack a single point of failure. You could still place racks into availability zones as in the previous example, but the value of availability zones is marginalized, since you need to have a double failure (e.g., both TORs in the rack failing) to take down a rack.
Ultimately with any of the above scenarios, the value added by your availability zones will depend on the likelihood and expression of failure modes &8211; both the ones you have designed for, and the ones you have not. But getting accurate and complete information on such failure modes may not be easy, so the value of availability zones from this kind of unplanned failure can be difficult to pin down.
There is however another area where availability zones have the potential to provide value &8212; planned maintenance. Have you ever needed to move, recable, upgrade, or rebuild a rack? Ever needed to shut off power to part of the data center to do electrical work? Ever needed to apply disruptive updates to your hypervisors, like kernel or QEMU security updates? How about upgrades of OpenStack or the hypervisor operating system?
Chances are good that these kinds of planned maintenance are a higher source of downtime than unplanned hardware failures that happen out of the blue. Therefore, this type of planned maintenance can also impact how you define your availability zones. In general the grouping of racks into availability zones (described previously) still works well, and is the most common availability zone paradigm we see for our customers.
However, it could affect the way in which you group your racks into availability zones. For example, you may choose to create availability zones based on physical parameters like which floor, room or building the equipment is located in, or other practical considerations that would help in the event you need to vacate or rebuild certain space in your DC(s). Ex:
One of the limitations of the OpenStack implementation of availability zones made apparent in this example is that you are forced to choose one definition. Applications can request a specific availability zone, but are not offered the flexibility of requesting building level isolation, vs floor, room, or rack level isolation. This will be a fixed, inherited property of the availability zones you create. If you need more, then you start to enter the realm of other OpenStack abstractions like Regions and Cells.
Other uses for availability zones?
Another way in which people have found to use availability zones is in multi-hypervisor environments. In the ideal world of the “implementation-agnostic” cloud, we would abstract such underlying details from users of our platform. However there are some key differences between hypervisors that make this aspiration difficult. Take the example of KVM & VMWare.
When an iSCSI target is provisioned through with the LVM iSCSI Cinder driver, it cannot be attached to or consumed by ESXi nodes. The provision request must go through VMWare’s VMDK Cinder driver, which proxies the creation and attachment requests to vCenter. This incompatibility can cause errors and thus a negative user experience issues if the user tries to attach a volume to their hypervisor provisioned from the wrong backend.
To solve this problem, some operators use availability zones as a way for users to select hypervisor types (for example, AZ_KVM1, AZ_VMWARE1), and set the following configuration in their nova.conf:
[cinder]
cross_az_attach = False
This presents users with an error if they attempt to attach a volume from one availability zone (e.g., AZ_VMWARE1) to another availability zone (e.g., AZ_KVM1). The call would have certainly failed regardless, but with a different error from farther downstream from one of the nova-compute agents, instead of from nova-api. This way, it&8217;s easier for the user to see where they went wrong and correct the problem.
In this case, the availability zone also acts as a tag to remind users which hypervisor their VM resides on.
In my opinion, this is stretching the definition of availability zones as failure domains. VMWare may be considered its own failure domain separate from KVM, but that’s not the primary purpose of creating availability zones this way. The primary purpose is to differentiate hypervisor types. Different hypervisor types have a different set of features and capabilities. If we think about the problem in these terms, there are a number of other solutions that come to mind:

Nova Flavors: Define a “VMWare” set of flavors that map to your VCenter cluster(s). If your tenants that use VMWare are different than your tenants who use KVM, you can make them private flavors, ensuring that tenants only ever see or interact with the hypervisor type they expect.
Cinder: Similarly for Cinder, you can make the VMWare backend private to specific tenants, and/or set quotas differently for that backend, to ensure that tenants will only allocate from the correct storage pools for their hypervisor type.
Image metadata: You can tag your images according to the hypervisor they run on. Set image property hypervisor_type to vmware for VMDK images, and to qemu for other images. The ComputeCapabilitiesFilter in Nova will honor the hypervisor placement request.

Soo… Are availability zones right for me?
So wrapping up, think of availability zones in terms of:

Unplanned failures: If you have a good history of failure data, well understood failure modes, or some known single point of failure that availability zones can help mitigate, then availability zones may be a good fit for your environment.
Planned maintenance: If you have well understood maintenance processes that have awareness of your availability zone definitions and can take advantage of them, then availability zones may be a good fit for your environment. This is where availability zones can provide some of the creates value, but is also the most difficult to achieve, as it requires intelligent availability zone-aware rolling updates and upgrades, and affects how data center personnel perform maintenance activities.
Tenant application design/support: If your tenants are running legacy apps, apps with single points of failure, or do not support use of availability zones in their provisioning process, then availability zones will be of no use for these workloads.
Other alternatives for achieving app availability: Workloads built for geo-redundancy can achieve the same level of HA (or better) in a multi-region cloud. If this were the case for your cloud and your cloud workloads, availability zones would be unnecessary.
OpenStack projects: You should factor into your decision the limitations and differences in availability zone implementations between different OpenStack projects, and perform this analysis for all OpenStack projects in your scope of deployment.

The post The first and final words on OpenStack availability zones appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

da Agency

The first and final words on OpenStack availability zones

The post The first and final words on OpenStack availability zones appeared first on Mirantis | Pure Play Open Cloud.
Availability zones are one of the most frequently misunderstood and misused constructs in OpenStack. Each cloud operator has a different idea about what they are and how to use them. What&#8217;s more, each OpenStack service implements availability zones differently &#8212; if it even implements them at all.
Often, there isn’t even agreement over the basic meaning or purpose of availability zones.
On the one hand, you have the literal interpretation of the words “availability zone”, which would lead us to think of some logical subdivision of resources into failure domains, allowing cloud applications to intelligently deploy in ways to maximize their availability. (We’ll be running with this definition for the purposes of this article.)
On the other hand, the different ways that projects implement availability zones lend themselves to certain ways of using the feature as a result. In other words, because this feature has been implemented in a flexible manner that does not tie us down to one specific concept of an availability zone, there&8217;s a lot of confusion over how to use them.
In this article, we&8217;ll look at the traditional definition of availability zones, insights into and best practices for planning and using them, and even a little bit about non-traditional uses. Finally, we hope to address the question: Are availability zones right for you?
OpenStack availability zone Implementations
One of the things that complicates use of availability zones is that each OpenStack project implements them in their own way (if at all). If you do plan to use availability zones, you should evaluate which OpenStack projects you&8217;re going to use support them, and how that affects your design and deployment of those services.
For the purposes of this article, we will look at three core services with respect to availability zones: #Nova, Cinder, and Neutron. We won&8217;t go into the steps to set up availability zones, but but instead we&8217;ll focus on a few of the key decision points, limitations, and trouble areas with them.
Nova availability zones
Since host aggregates were first introduced in OpenStack Grizzly, I have seen a lot of confusion about availability zones in Nova. Nova tied their availability zone implementation to host aggregates, and because the latter is a feature unique to the Nova project, its implementation of availability zones is also unique.
I have had many people tell me they use availability zones in Nova, convinced they are not using host aggregates. Well, I have news for these people &8212; all* availability zones in Nova are host aggregates (though not all host aggregates are availability zones):
* Exceptions being the default_availability_zone that compute nodes are placed into when not in another user-defined availability zone, and the internal_service_availability_zone where other nova services live
Some of this confusion may come from the nova CLI. People may do a quick search online, see they can create an availability zone with one command, and may not realize that they’re actually creating a host aggregate. Ex:
$ nova aggregate-create <aggregate name> <AZ name>
$ nova aggregate-create HA1 AZ1
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 4  |   HA1   | AZ1               |       | ‘availability_zone=AZ1’|
+—-+———+——————-+——-+————————+
I have seen people get confused with the second argument (the AZ name). This is just a shortcut for setting the availability_zone metadata for a new host aggregate you want to create.
This command is equivalent to creating a host aggregate, and then setting the metadata:
$ nova aggregate-create HA1
+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 7  |   HA1   | –                 |       |          |
+—-+———+——————-+——-+———-+
$ nova aggregate-set-metadata HA1 availability_zone=AZ1
Metadata has been successfully updated for aggregate 7.
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 7  |   HA1   | AZ1               |       | ‘availability_zone=AZ1’|
+—-+———+——————-+——-+————————+
Doing it this way, it’s more apparent that the workflow is the same as any other host aggregate, the only difference is the “magic” metadata key availability_zone which we set to AZ1 (notice we also see AZ1 show up under the Availability Zone column). And now when we add compute nodes to this aggregate, they will be automatically transferred out of the default_availability_zone and into the one we have defined. For example:
Before:
$ nova availability-zone-list
| nova              | available                              |
| |- node-27        |                                        |
| | |- nova-compute | enabled :-) 2016-11-06T05:13:48.000000 |
+——————-+—————————————-+
After:
$ nova availability-zone-list
| AZ1               | available                              |
| |- node-27        |                                        |
| | |- nova-compute | enabled :-) 2016-11-06T05:13:48.000000 |
+——————-+—————————————-+
Note that there is one behavior that sets apart the availability zone host aggregates apart from others. Namely, nova does not allow you to assign the same compute host to multiple aggregates with conflicting availability zone assignments. For example, we can first add compute a node to the previously created host aggregate with availability zone AZ1:
$ nova aggregate-add-host HA1 node-27
Host node-27 has been successfully added for aggregate 7
+—-+——+——————-+———-+————————+
| Id | Name | Availability Zone | Hosts    | Metadata               |
+—-+——+——————-+———-+————————+
| 7  | HA1  | AZ1               | ‘node-27’| ‘availability_zone=AZ1’|
+—-+——+——————-+———-+————————+
Next, we create a new host aggregate for availability zone AZ2:
$ nova aggregate-create HA2

+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 13 |   HA2   | –                 |       |          |
+—-+———+——————-+——-+———-+

$ nova aggregate-set-metadata HA2 availability_zone=AZ2
Metadata has been successfully updated for aggregate 13.
+—-+———+——————-+——-+————————+
| Id | Name    | Availability Zone | Hosts | Metadata               |
+—-+———+——————-+——-+————————+
| 13 |   HA2   | AZ2               |       | ‘availability_zone=AZ2’|
+—-+———+——————-+——-+————————+
Now if we try to add the original compute node to this aggregate, we get an error because this aggregate has a conflicting availability zone:
$ nova aggregate-add-host HA2 node-27
ERROR (Conflict): Cannot add host node-27 in aggregate 13: host exists (HTTP 409)
+—-+——+——————-+———-+————————+
| Id | Name | Availability Zone | Hosts    | Metadata               |
+—-+——+——————-+———-+————————+
| 13 | HA2  | AZ2               |          | ‘availability_zone=AZ2’|
+—-+——+——————-+———-+————————+
(Incidentally, it is possible to have multiple host aggregates with the same availability_zone metadata, and add the same compute host to both. However, there are few, if any, good reasons for doing this.)
In contrast, Nova allows you to assign this compute node to another host aggregate with other metadata fields, as long as the availability_zone doesn&8217;t conflict:
You can see this if you first create a third host aggregate:
$ nova aggregate-create HA3
+—-+———+——————-+——-+———-+
| Id | Name    | Availability Zone | Hosts | Metadata |
+—-+———+——————-+——-+———-+
| 16 |   HA3   | –                 |       |          |
+—-+———+——————-+——-+———-+
Next, tag  the host aggregate for some purpose not related to availability zones (for example, an aggregate to track compute nodes with SSDs):
$ nova aggregate-set-metadata HA3 ssd=True
Metadata has been successfully updated for aggregate 16.
+—-+———+——————-+——-+———–+
| Id | Name    | Availability Zone | Hosts |  Metadata |
+—-+———+——————-+——-+———–+
| 16 |   HA3   | –                 |       | ‘ssd=True’|
+—-+———+——————-+——-+———–+
Adding original node to another aggregate without conflicting availability zone metadata works:
$ nova aggregate-add-host HA3 node-27
Host node-27 has been successfully added for aggregate 16
+—-+——-+——————-+———–+————+
| Id | Name  | Availability Zone | Hosts     |  Metadata  |
+—-+——-+——————-+———–+————+
| 16 | HA3   | –                 | ‘node-27′ | ‘ssd=True’ |
+—-+——-+——————-+———–+————+
(Incidentally, Nova will also happily let you assign the same compute node to another aggregate with ssd=False for metadata, even though that clearly doesn&8217;t make sense. Conflicts are only checked/enforced in the case of the availability_zone metadata.)
Nova configuration also holds parameters relevant to availability zone behavior. In the nova.conf read by your nova-api service, you can set a default availability zone for scheduling, which is used if users do not specify an availability zone in the API call:
[DEFAULT]
default_schedule_zone=AZ1
However, most operators leave this at its default setting (None), because it allows users who don’t care about availability zones to omit it from their API call, and the workload will be scheduled to any availability zone where there is available capacity.
If a user requests an invalid or undefined availability zone, the Nova API will report back with an HTTP 400 error. There is no availability zone fallback option.
Cinder
Creating availability zones in Cinder is accomplished by setting the following configuration parameter in cinder.conf, on the nodes where your cinder-volume service runs:
[DEFAULT]
storage_availability_zone=AZ1
Note that you can only set the availability zone to one value. This is consistent with availability zones in other OpenStack projects that do not allow for the notion of overlapping failure domains or multiple failure domain levels or tiers.
The change takes effect when you restart your cinder-volume services. You can confirm your availability zone assignments as follows:
cinder service-list
+—————+——————-+——+———+——-+
|     Binary    |        Host       | Zone | Status  | State |
+—————+——————-+——+———+——-+
| cinder-volume | hostname1@LVM     |  AZ1 | enabled |   up  |
| cinder-volume | hostname2@LVM     |  AZ2 | enabled |   up  |
If you would like to establish a default availability zone, you can set the this parameter in cinder.conf on the cinder-api nodes:
[DEFAULT]
default_availability_zone=AZ1
This instructs Cinder which availability zone to use if the API call did not specify one. If you don’t, it will use a hardcoded default, nova. In the case of our example, where we&8217;ve set the default availability zone in Nova to AZ1, this would result in a failure. This also means that unlike Nova, users do not have the flexibility of omitting availability zone information and expecting that Cinder will select any available backend with spare capacity in any availability zone.
Therefore, you have a choice with this parameter. You can set it to one of your availability zones so API calls without availability zone information don’t fail, but causing a potential situation of uneven storage allocation across your availability zones. Or, you can not set this parameter, and accept that user API calls that forget or omit availability zone info will fail.
Another option is to set the default to a non-existent availability zone you-must-specify-an-AZ or something similar, so when the call fails due to the non-existant availability zone, this information will be included in the error message sent back to the client.
Your storage backends, storage drivers, and storage architecture may also affect how you set up your availability zones. If we are using the reference Cinder LVM ISCSI Driver deployed on commodity hardware, and that hardware fits the same availability zone criteria of our computes, then we could setup availability zones to match what we have defined in Nova. We could also do the same if we had a third party storage appliance in each availability zone, e.g.:
|     Binary    |           Host          | Zone | Status  | State |
| cinder-volume | hostname1@StorageArray1 |  AZ1 | enabled |   up  |
| cinder-volume | hostname2@StorageArray2 |  AZ2 | enabled |   up  |
(Note: Notice that the hostnames (hostname1 and hostname2) are still different in this example. The cinder multi-backend feature allows us to configure multiple storage backends in the same cinder.conf (for the same cinder-volume service), but Cinder availability zones can only be defined per cinder-volume service, and not per-backend per-cinder-volume service. In other words, if you define multiple backends in one cinder.conf, they will all inherit the same availability zone.)
However, in many cases if you’re using a third party storage appliance, then these systems usually have their own built-in redundancy that exist outside of OpenStack notions of availability zones. Similarly if you use a distributed storage solution like Ceph, then availability zones have little or no meaning in this context. In this case, you can forgo Cinder availability zones.
The one issue in doing this, however, is that any availability zones you defined for Nova won’t match. This can cause problems when Nova makes API calls to Cinder &#8211; for example, when performing a Boot from Volume API call through Nova. If Nova decided to provision your VM in AZ1, it will tell Cinder to provision a boot volume in AZ1, but Cinder doesn’t know anything about AZ1, so this API call will fail. To prevent this from happening, we need to set the following parameter in cinder.conf on your nodes running cinder-api:
[DEFAULT]
allow_availability_zone_fallback=True
This parameter prevents the API call from failing, because if the requested availability zone does not exist, Cinder will fallback to another availability zone (whichever you defined in default_availability_zone parameter, or in storage_availability_zone if the default is not set). The hardcoded default storage_availability_zone is nova, so the fallback availability zone should match the default availability zone for your cinder-volume services, and everything should work.
The easiest way to solve the problem, however is to remove the AvailabilityZoneFilter from your filter list in cinder.conf on nodes running cinder-scheduler. This makes the scheduler ignore any availability zone information passed to it altogether, which may also be helpful in case of any availability zone configuration mismatch.
Neutron
Availability zone support was added to Neutron in the Mitaka release. Availability zones can be set for DHCP and L3 agents in their respective configuration files:
[AGENT]
Availability_zone = AZ1
Restart the agents, and confirm availability zone settings as follows:
neutron agent-show <agent-id>
+———————+————+
| Field               | Value      |
+———————+————+
| availability_zone   | AZ1        |
…
If you would like to establish a default availability zone, you can set the this parameter in neutron.conf on neutron-server nodes:
[DEFAULT]
default_availability_zones=AZ1,AZ2
This parameters tells Neutron which availability zones to use if the API call did not specify any. Unlike Cinder, you can specify multiple availability zones, and leaving it undefined places no constraints in scheduling, as there are no hard coded defaults. If you have users making API calls that do not care about the availability zone, then you can enumerate all your availability zones for this parameter, or simply leave it undefined &8211; both would yield the same result.
Additionally, when users do specify an availability zone, such requests are fulfilled as a “best effort” in Neutron. In other words, there is no need for an availability zone fallback parameter, because your API call still execute even if your availability zone hint can’t be satisfied.
Another important distinction that sets Neutron aside from Nova and Cinder is that it implements availability zones as scheduler hints, meaning that on the client side you can repeat this option to chain together multiple availability zone specifications in the event that more than one availability zone would satisfy your availability criteria. For example:
$ neutron net-create –availability-zone-hint AZ1 –availability-zone-hint AZ2 new_network
As with Cinder, the Neutron plugins and backends you’re using deserve attention, as the support or need for availability zones may be different depending on their implementation. For example, if you’re using a reference Neutron deployment with the ML2 plugin and with DHCP and L3 agents deployed to commodity hardware, you can likely place these agents consistently according to the same availability zone criteria used for your computes.
Whereas in contrast, other alternatives such as the Contrail plugin for Neutron do not support availability zones. Or if you are using Neutron DVR for example, then availability zones have limited significance for Layer 3 Neutron.
OpenStack Project availability zone Comparison Summary
Before we move on, it&8217;s helpful to review how each project handles availability zones.

Nova
Cinder
Neutron

Default availability zone scheduling
Can set to one availability zone or None
Can set one availability zone; cannot set None
Can set to any list of availability zones or none

Availability zone fallback
None supported
Supported through configuration
N/A; scheduling to availability zones done on a best effort basis

Availability zone definition restrictions
No more than #1 availability zone per nova-compute
No more than 1 availability zone per cinder-volume
No more than 1 availability zone per neutron agent

Availability zone client restrictions
Can specify one availability zone or none
Can specify one availability zone or none
Can specify an arbitrary number of availability zones

Availability zones typically used when you have &#8230;
Commodity HW for computes, libvirt driver
Commodity HW for storage, LVM iSCSI driver
Commodity HW for neutron agents, ML2 plugin

Availability zones not typically used when you have&8230;
Third party hypervisor drivers that manage their own HA for VMs (DRS for VCenter)
Third party drivers, backends, etc. that manage their own HA
Third party plugins, backends, etc. that manage their own HA

Best Practices for availability zones
Now let&8217;s talk about how to best make use of availability zones.
What should my availability zones represent?
The first thing you should do as a cloud operator is to nail down your own accepted definition of an availability zone and how you will use them, and remain consistent. You don’t want to end up in a situation where availability zones are taking on more than one meaning in the same cloud. For example:
Fred’s AZ            | Example of AZ used to perform tenant workload isolation
VMWare cluster 1 AZ | Example of AZ used to select a specific hypervisor type
Power source 1 AZ   | Example of AZ used to select a specific failure domain
Rack 1 AZ           | Example of AZ used to select a specific failure domain
Such a set of definitions would be a source of inconsistency and confusion in your cloud. It’s usually better to keep things simple with one availability zone definition, and use OpenStack features such as Nova Flavors or Nova/Cinder boot hints to achieve other requirements for multi-tenancy isolation, ability to select between different hypervisor options and other features, and so on.
Note that OpenStack currently does not support the concept of multiple failure domain levels/tiers. Even though we may have multiple ways to define failure domains (e.g., by power circuit, rack, room, etc), we must pick a single convention.
For the purposes of this article, we will discuss availability zones in the context of failure domains. However, we will cover one other use for availability zones in the third section.
How many availability zones do I need?
One question that customers frequently get hung up on is how many availability zones they should create. This can be tricky because the setup and management of availability zones involves stakeholders at every layer of the solution stack, from tenant applications to cloud operators, down to data center design and planning.

A good place to start is your cloud application requirements: How many failure domains are they designed to work with (i.e. redundancy factor)? The likely answer is two (primary + backup), three (for example, for a database or other quorum-based system), or one (for example, a legacy app with single points of failure). Therefore, the vast majority of clouds will have either 2, 3, or 1 availability zone.
Also keep in mind that as a general design principle, you want to minimize the number of availability zones in your environment, because the side effect of availability zone proliferation is that you are dividing your capacity into more resource islands. The resource utilization in each island may not be equal, and now you have an operational burden to track and maintain capacity in each island/availability zone. Also, if you have a lot of availability zones (more than the redundancy factor of tenant applications), tenants are left to guess which availability zones to use and which have available capacity.
How do I organize my availability zones?
The value proposition of availability zones is that tenants are able to achieve a higher level of availability in their applications. In order to make good on that proposition, we need to design our availability zones in ways that mitigate single points of failure.             
For example, if our resources are split between two power sources in the data center, then we may decide to define two resource pools (availability zones) according to their connected power source:
Or, if we only have one TOR switch in our racks, then we may decide to define availability zones by rack. However, here we can run into problems if we make each rack its own availability zone, as this will not scale from a capacity management perspective for more than 2-3 racks/availability zones (because of the &#8220;resource island&#8221; problem). In this case, you might consider dividing/arranging your total rack count into into 2 or 3 logical groupings that correlate to your defined availability zones:
We may also find situations where we have redundant TOR switch pairs in our racks, power source diversity to each rack, and lack a single point of failure. You could still place racks into availability zones as in the previous example, but the value of availability zones is marginalized, since you need to have a double failure (e.g., both TORs in the rack failing) to take down a rack.
Ultimately with any of the above scenarios, the value added by your availability zones will depend on the likelihood and expression of failure modes &8211; both the ones you have designed for, and the ones you have not. But getting accurate and complete information on such failure modes may not be easy, so the value of availability zones from this kind of unplanned failure can be difficult to pin down.
There is however another area where availability zones have the potential to provide value &8212; planned maintenance. Have you ever needed to move, recable, upgrade, or rebuild a rack? Ever needed to shut off power to part of the data center to do electrical work? Ever needed to apply disruptive updates to your hypervisors, like kernel or QEMU security updates? How about upgrades of OpenStack or the hypervisor operating system?
Chances are good that these kinds of planned maintenance are a higher source of downtime than unplanned hardware failures that happen out of the blue. Therefore, this type of planned maintenance can also impact how you define your availability zones. In general the grouping of racks into availability zones (described previously) still works well, and is the most common availability zone paradigm we see for our customers.
However, it could affect the way in which you group your racks into availability zones. For example, you may choose to create availability zones based on physical parameters like which floor, room or building the equipment is located in, or other practical considerations that would help in the event you need to vacate or rebuild certain space in your DC(s). Ex:
One of the limitations of the OpenStack implementation of availability zones made apparent in this example is that you are forced to choose one definition. Applications can request a specific availability zone, but are not offered the flexibility of requesting building level isolation, vs floor, room, or rack level isolation. This will be a fixed, inherited property of the availability zones you create. If you need more, then you start to enter the realm of other OpenStack abstractions like Regions and Cells.
Other uses for availability zones?
Another way in which people have found to use availability zones is in multi-hypervisor environments. In the ideal world of the “implementation-agnostic” cloud, we would abstract such underlying details from users of our platform. However there are some key differences between hypervisors that make this aspiration difficult. Take the example of KVM & VMWare.
When an iSCSI target is provisioned through with the LVM iSCSI Cinder driver, it cannot be attached to or consumed by ESXi nodes. The provision request must go through VMWare’s VMDK Cinder driver, which proxies the creation and attachment requests to vCenter. This incompatibility can cause errors and thus a negative user experience issues if the user tries to attach a volume to their hypervisor provisioned from the wrong backend.
To solve this problem, some operators use availability zones as a way for users to select hypervisor types (for example, AZ_KVM1, AZ_VMWARE1), and set the following configuration in their nova.conf:
[cinder]
cross_az_attach = False
This presents users with an error if they attempt to attach a volume from one availability zone (e.g., AZ_VMWARE1) to another availability zone (e.g., AZ_KVM1). The call would have certainly failed regardless, but with a different error from farther downstream from one of the nova-compute agents, instead of from nova-api. This way, it&8217;s easier for the user to see where they went wrong and correct the problem.
In this case, the availability zone also acts as a tag to remind users which hypervisor their VM resides on.
In my opinion, this is stretching the definition of availability zones as failure domains. VMWare may be considered its own failure domain separate from KVM, but that’s not the primary purpose of creating availability zones this way. The primary purpose is to differentiate hypervisor types. Different hypervisor types have a different set of features and capabilities. If we think about the problem in these terms, there are a number of other solutions that come to mind:

Nova Flavors: Define a “VMWare” set of flavors that map to your VCenter cluster(s). If your tenants that use VMWare are different than your tenants who use KVM, you can make them private flavors, ensuring that tenants only ever see or interact with the hypervisor type they expect.
Cinder: Similarly for Cinder, you can make the VMWare backend private to specific tenants, and/or set quotas differently for that backend, to ensure that tenants will only allocate from the correct storage pools for their hypervisor type.
Image metadata: You can tag your images according to the hypervisor they run on. Set image property hypervisor_type to vmware for VMDK images, and to qemu for other images. The ComputeCapabilitiesFilter in Nova will honor the hypervisor placement request.

Soo… Are availability zones right for me?
So wrapping up, think of availability zones in terms of:

Unplanned failures: If you have a good history of failure data, well understood failure modes, or some known single point of failure that availability zones can help mitigate, then availability zones may be a good fit for your environment.
Planned maintenance: If you have well understood maintenance processes that have awareness of your availability zone definitions and can take advantage of them, then availability zones may be a good fit for your environment. This is where availability zones can provide some of the creates value, but is also the most difficult to achieve, as it requires intelligent availability zone-aware rolling updates and upgrades, and affects how data center personnel perform maintenance activities.
Tenant application design/support: If your tenants are running legacy apps, apps with single points of failure, or do not support use of availability zones in their provisioning process, then availability zones will be of no use for these workloads.
Other alternatives for achieving app availability: Workloads built for geo-redundancy can achieve the same level of HA (or better) in a multi-region cloud. If this were the case for your cloud and your cloud workloads, availability zones would be unnecessary.
OpenStack projects: You should factor into your decision the limitations and differences in availability zone implementations between different OpenStack projects, and perform this analysis for all OpenStack projects in your scope of deployment.

The post The first and final words on OpenStack availability zones appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis