8221 News, Entwicklungen, Updates, HowTos - Seite 5 von 14

In December 2016, a major vulnerability, CVE-2016-9962 (“on-entry vulnerability”), was found in the Docker engine which allowed local root users in a container to gain access to file-descriptors of a process launched or moved into the container from another namespace. In a Banyan security report, they found that over 30% of official images in Docker Hub contain high priority security vulnerabilities. And FlawCheck surveyed enterprises asking for their top security concern regarding containers in production environments. “Vulnerabilities and malware,” at 42%, was the top security concern among those surveyed. Clearly security is a top concern for organizations that are looking to run containers in production.
At Red Hat, we are continuously improving our security capabilities and introduced a new container scanning feature with CloudForms 4.2 and OpenShift 3.4. This new feature allows CloudForms to flag images in the container registry in which it has found vulnerabilities, and OpenShift to deny execution of that image the next time someone tries to run that image.

CloudForms has multiple capabilities on how a container scan can be initiated:

A scheduled scan of the registry
An automatic scan based on newly discovered images in the registry
A manual execution of the scan via Smart-tate Analysis

Having this unique scanning feature with native integration in OpenShift is a milestone in container security as it provides near real time monitoring of your images within the OpenShift environment.
The following diagram illustrates the flow happening when an automatic scan is performed.

CloudForms monitors the OpenShift Provider and checks for new images in the registry. If it finds a new image, CloudForms triggers a scan.
CloudForms makes a secure call to OpenShift and requests a scanning container to be scheduled.
OpenShift schedules a new pod on an available node.
The scanning container is started.
The scanning container pulls down a copy of the image to scan.
The image to scan is unpacked and its software contents (RPMs) are sent to CloudForms.
CloudForms may also initiate an OpenSCAP scan of the container.
Once the OpenSCAP scan finishes, the results are uploaded and a report is generated from the CloudForms UI.
If the scan found any vulnerabilities, CloudForms calls OpenShift to flag the image and prevent it from running.

The next time someone tries to start the vulnerable image, OpenShift alerts the user that the image execution was blocked based on the policy set by CloudForms.

As you can see, Red Hat CloudForms can be used as part of your IT security and compliance management to assist in identifying and validating that workloads are secure across your infrastructure stack, starting with hosts and virtual machines, instances in the cloud, or containers.
Quelle: CloudForms

25. Februar 201725. Februar 2017

da Agency

53 new things to look for in OpenStack Ocata

The post 53 new things to look for in OpenStack Ocata appeared first on Mirantis | Pure Play Open Cloud.
With a shortened development cycle, you’d think we&8217;d have trouble finding 53 new features of interest in OpenStack Ocata, but with so many projects (more than 60!) under the Big Tent, we actually had a little bit of trouble narrowing things down. We did a live webinar talking about 157 new features, but here&8217;s our standard 53. (Thanks to the PTLs who helped us out with weeding it down from the full release notes!)
Nova (OpenStack Compute Service)

VM placement changes: The Nova filter scheduler will now use the Placement API to filter compute nodes based on CPU/RAM/Disk capacity.
High availability: Nova now uses Cells v2 for all deployments; currently implemented as single cells, the next release, Pike, will support multi-cell clouds.
Neutron is now the default networking option.
Upgrade capabilities: Use the new ‘nova-status upgrade check&8217; CLI command to see what&8217;s required to upgrade to Ocata.

Keystone (OpenStack Identity Service)

Per-user Multi-Factor-Auth rules (MFA rules): You can now specify multiple forms of authentication before Keystone will issue a token. For example, some users might just need a password, while others might have to provide a time-based one time password and an additional form of authentication.
Auto-provisioning for federated identity: When a user logs into a federated system, Keystone will dynamically create that user a role; previously, the user had to log into that system independently, which was confusing to users.
Validate an expired token: Finally, no more failures due to long-running operations such as uploading a snapshot. Each project can specify whether it will accept expired tokens, and just HOW expired those tokens can be.

Swift (OpenStack Object Storage)

Improved compatibility: Byteorder information is now included in Ring files to support machines with different endianness.
More flexibility: You can now configure the base of the URL base for static web. You can also set the “filename” parameter in TempURLs and validate those TempURLs against a common prefix.
More data: If you&8217;re dealing with large objects, you can now use multi-range GETs and HTTP 416 responses.

Cinder (OpenStack Block Storage)

Active/Active HA: Cinder can now run in Active/Active clustered mode, preventing concurrent operation conflicts. Cinder will also handle mid-processing service failures better than in past releases.
New attach/detach APIs: If you&8217;ve been confused about how to attach and detach volumes to and from VMs, you&8217;re not alone. The Ocata release saw the Cinder team refactor these APIs in preparation for adding the ability to attach a single volume to multiple VMs, expected in an upcoming release.

Glance (OpenStack Image Service)

Image visibility: Users can now create &8220;community&8221; images, making them available for everyone else to use. You can also specify an image as &8220;shared&8221; to specify that only certain users have access.

Neutron (OpenStack Networking Service)

Support for Routed Provider Networks in Neutron: You can now use the NOVA GRP (Generic Resource Pools) API to publish networks in IPv4 inventory. Also, the Nova scheduler uses this inventory as a hint to place instances based on IPv4 address availability in routed network segments.
Resource tag mechanism: You can now create tags for subnet, port, subnet pool and router resources, making it possible to do things like map different networks in different OpenStack clouds in one logical network or tag provider networks (i.e. High-speed, High-Bandwidth, Dial-Up).

Heat (OpenStack Orchestration Service)

Notification and application workflow: Use the new OS::Zaqar::Notification to subscribe to Zaqar queues for notifications, or the OS::Zaqar::MistralTrigger for just Mistral notifications.

Horizon (OpenStack Dashboard)

Easier profiling and debugging: The new Profiler Panel uses the os-profiler library to provide profiling of requests through Horizon to the OpenStack APIs so you can see what&8217;s going on inside your cloud.
Easier Federation configuration: If Keystone is configured with Keystone to Keystone (K2K) federation and has service providers, you can now choose Keystone providers from a dropdown menu.

Telemetry (Ceilometer)

Better instance discovery: Ceilometer now uses libvirt directly by default, rather than nova-api.

Telemetry (Gnocchi)

Dynamically resample measures through a new API.
New collectd plugin: Store metrics generated by collectd.
Store data on Amazon S3 with new storage driver.

Dragonflow (Distributed SDN Controller)

Better support for modern networking: Dragonflow now supports IPv6 and distributed sNAT.
Live migration: Dragonflow now supports live migration of VMs.

Kuryr (Container Networking)

Neutron support: Neutron networking is now available to containers running inside a VM. For example, you can now assign one Neutron port per container.
More flexibility with driver-based support: Kuryr-libnetwork now allows you to choose between ipvlan, macvlan or Neutron vlan trunk ports or even create your own driver. Also, Kuryr-kubernetes has support for ovs hybrid, ovs native and Dragonflow.
Container Networking Interface (CNI): You can now use the Kubernetes CNI with Kuryr-kubernetes.
More platforms: The controller now handles Pods on bare metal, handles Pods in VMs by providing them Neutron subports, and provides services with LBaaSv2.

Vitrage (Root Cause Analysis Service)

A new collectd datasource: Use this fast system statistics collection deamon, with plugins that collect different metrics. From Ifat Afek: &8220;We tested the DPDK plugin, that can trigger alarms such as interface failure or noisy neighbors. Based on these alarms, Vitrage can deduce the existence of problems in the host, instances and applications, and provide the RCA (Root Cause Analysis) for these problems.&8221;
New “post event” API: Use This general-purpose API allows easy integration of new monitors into Vitrage.
Multi Tenancy support: A user will only see alarms and resources which belong to that user&8217;s tenant.

Ironic (Bare Metal Service)

Easier, more powerful management: A revamp of how drivers are composed, &8220;dynamic drivers&8221; enable users to select a &8220;hardware type&8221; for a machine rather than working through a matrix of hardware types. Users can independently change the deploy method, console manager, RAID management, power control interface and so on. Ocata also brings the ability to do soft power off and soft reboot, and to send non-maskable interrupts through both ironic and nova&8217;s API.

TripleO (Deployment Service)

Easier per-service upgrades: Perform step-by-step tasks as batched/rolling upgrades or in parallel. All roles, including custom roles, can be upgraded this way.
Composable High-Availability architecture: Services managed by Pacemaker such as galera, redis, VIPs, haproxy, cinder-volume, rabbitmq, cinder-backup, and manila-share can now be deployed in multiple clusters, making it possible to scale-out the number of nodes running these services.

OpenStackAnsible (Ansible Playbooks and Roles for Deployment)

Additional support: OpenStack-Ansible now supports CentOS 7, as well as integration with Ceph.

Puppet OpenStack (Puppet Modules for Deployment)

New modules and functionality: The Ocata release includes new modules for puppet-ec2api, puppet-octavia, puppet-panko and puppet-watcher. Also, existing modules support configuring the [DEFAULT]/transport_url configuration option. This changes makes it possible to support AMQP providers other than rabbitmq, such as zeromq.

Barbican (Key Manager Service)

Testing: Barbican now includes a new Tempest test framework.

Congress (Governance Service)

Network address operations: The policy language has been enhanced to enable users to specify network network policy use cases.
Quick start: Congress now includes a default policy library so that it&8217;s useful out of the box.

Monasca (Monitoring)

Completion of Logging-as-a-Service: Kibana support and integration is now complete, enabling you to push/publish logs to the Monasca Log API, and the logs are authenticated and authorized using Keystone and stored scoped to a tenant/project, so users can only see information from their own logs.
Container support: Monasca now supports monitoring of Docker containers, and is adding support for the Prometheus monitoring solution. Upcoming releases will also see auto-discovery and monitoring of applications launched in a Kubernetes cluster.

Trove (Database as a Service)

Multi-region deployments: Database clusters can now be deployed across multiple OpenStack regions.

Mistral (Taskflow as a Service)

Multi-node mode: You can now deploy the Mistral engine in multi-node mode, providing the ability to scale out.

Rally (Benchmarking as a Service)

Expanded verification options: Whereas previous versions enabled you to use only Tempest to verify your cluster, the newest version of Rally enables you to use other forms of verification, which means that Rally can actually be used for the non-OpenStack portions of your application and infrastructure. (You can find the full release notes here.)

Zaqar (Message Service)

Storage replication: You can now use Swift as a storage option, providing built-in replication capabilities.

Octavia (Load Balancer Service)

More flexibility for Load Balancer as a Service: You may now use neutron host-routes and custom MTU configurations when configuring LBaasS.

Solum (Platform as a Service)

Responsive deployment: You may now configure deployments based on Github triggers, which means that you can implement CI/CD by specifying that your application should redeploy when there are changes.

Tricircle (Networking Automation Across Neutron Service)

DVR support in local Neutron: The East-West and North-South bridging network have been combined into North-South a bridging network, making it possible to support DVR in local Neutron.

Kolla (Container Based Deployment)

Dynamic volume provisioning: Kolla-Kubernetes by default uses Ceph for stateful storage, and with Kubernetes 1.5, support was added for Ceph and dynamic volume provisioning as requested by claims made against the API server.

Freezer (Backup, Restore, and Disaster Recovery Service)

Block incremental backups: Ocata now includes the Rsync engine, enabling these incremental backups.

Senlin (Clustering Service)

Generic Event/Notification support: In addition to its usual capability of logging events to a database, Senlin now enables you to add the sending of events to a message queue and to a log file, enabling dynamic monitoring.

Watcher (Infrastructure Optimization Service)

Multiple-backend support: Watcher now supports metrics collection from multiple backends.

Cloudkitty (Rating Service)

Easier management: CloudKitty now includes a Horizon wizard and hints on the CLI to determine the available metrics. Also, Cloudkitty is now part of the unified OpenStack client.

The post 53 new things to look for in OpenStack Ocata appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

25. Februar 201725. Februar 2017

da Agency

53 new things to look for in OpenStack Ocata

Keystone (OpenStack Identity Service)

Swift (OpenStack Object Storage)

Cinder (OpenStack Block Storage)

Glance (OpenStack Image Service)

Neutron (OpenStack Networking Service)

Heat (OpenStack Orchestration Service)

Notification and application workflow: Use the new OS::Zaqar::Notification to subscribe to Zaqar queues for notifications, or the OS::Zaqar::MistralTrigger for just Mistral notifications.

Horizon (OpenStack Dashboard)

Telemetry (Ceilometer)

Better instance discovery: Ceilometer now uses libvirt directly by default, rather than nova-api.

Telemetry (Gnocchi)

Dynamically resample measures through a new API.
New collectd plugin: Store metrics generated by collectd.
Store data on Amazon S3 with new storage driver.

Dragonflow (Distributed SDN Controller)

Better support for modern networking: Dragonflow now supports IPv6 and distributed sNAT.
Live migration: Dragonflow now supports live migration of VMs.

Kuryr (Container Networking)

Vitrage (Root Cause Analysis Service)

Ironic (Bare Metal Service)

TripleO (Deployment Service)

OpenStackAnsible (Ansible Playbooks and Roles for Deployment)

Additional support: OpenStack-Ansible now supports CentOS 7, as well as integration with Ceph.

Puppet OpenStack (Puppet Modules for Deployment)

Barbican (Key Manager Service)

Testing: Barbican now includes a new Tempest test framework.

Congress (Governance Service)

Monasca (Monitoring)

Trove (Database as a Service)

Multi-region deployments: Database clusters can now be deployed across multiple OpenStack regions.

Mistral (Taskflow as a Service)

Multi-node mode: You can now deploy the Mistral engine in multi-node mode, providing the ability to scale out.

Rally (Benchmarking as a Service)

Zaqar (Message Service)

Storage replication: You can now use Swift as a storage option, providing built-in replication capabilities.

Octavia (Load Balancer Service)

More flexibility for Load Balancer as a Service: You may now use neutron host-routes and custom MTU configurations when configuring LBaasS.

Solum (Platform as a Service)

Responsive deployment: You may now configure deployments based on Github triggers, which means that you can implement CI/CD by specifying that your application should redeploy when there are changes.

Tricircle (Networking Automation Across Neutron Service)

DVR support in local Neutron: The East-West and North-South bridging network have been combined into North-South a bridging network, making it possible to support DVR in local Neutron.

Kolla (Container Based Deployment)

Freezer (Backup, Restore, and Disaster Recovery Service)

Block incremental backups: Ocata now includes the Rsync engine, enabling these incremental backups.

Senlin (Clustering Service)

Watcher (Infrastructure Optimization Service)

Multiple-backend support: Watcher now supports metrics collection from multiple backends.

Cloudkitty (Rating Service)

Easier management: CloudKitty now includes a Horizon wizard and hints on the CLI to determine the available metrics. Also, Cloudkitty is now part of the unified OpenStack client.

The post 53 new things to look for in OpenStack Ocata appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

16. Februar 201716. Februar 2017

da Agency

3 key ways streaming video helps with delivering tough corporate news

Whether it’s a lower-than-expected earnings period or layoffs, every company has to find a way to announce bad news.
Historically, the news was delivered with a memo or in an in-person meeting, but these no longer suffice as workforces become increasingly distributed. Fortunately, the introduction of streaming video technology has upended how businesses communicate changes to large numbers of workers for the better.
“It’s efficient, you can reach a wide audience at a low cost, and the products available for this are extremely affordable” says Dan Rayburn, a streaming media analyst for Frost & Sullivan and executive vice president of streamingmedia.com. Rayburn adds that major companies, including Goldman Sachs and Coca-Cola, are already taking advantage.
Most importantly, streaming video enables three critical elements necessary in delivering tough news to employees:
Transparency
According to research from McKinsey & Company about company transformations, employees are eight times more likely to report a success when their bosses communicate directly. Streaming video not only enables company-wide, simultaneous communication, but also allows sometimes inaccessible C-level executives to communicate directly and clearly with all employees.
What&8217;s more, streaming video facilitates an open conversation between employees and senior management. As an executive communicates a message to the employees, an HR manager can sift through pertinent questions submitted by employees on the platform in real-time. Executives can then address these questions to help employees understand what&8217;s going on.
Personalization
With streaming video, a single message can not only be delivered across a large company, but also tailored to that company&8217;s different locations. Following an initial announcement, companies can integrate additional messages that pertain specifically to varying regions or departments. This is particularly useful for globally distributed companies where employees may be impacted differently depending on their location.
Video streaming enables both a uniform message and smaller video conversations that provide details on, for example, each person&8217;s severance package. According to Valerie Frederickson, CEO of the HR consultancy Frederickson Pribula Li, even if a company is confined to a relatively small geographic region in a single time zone, any company with more than 75 employees should consider itself a candidate for streaming video services.
Consistency
Streaming video can be tailored to meet individual needs, interests and circumstances, but it can also prevent variation in messages from the leadership team to employees.
“How can the company give the message all around the world, how can they convey that it&8217;s under control?&8221; asks Frederickson. “What you want to have in streaming video is an executive at the top or near the top who is disciplined and can stay on point.&8221;
Video streaming controls for anomalies that may appear if the job of delivering the news were given entirely to local managers. This is essential for preventing an internal misalignment that might lead to conflicts.
Consistency also implies communication is ongoing. Whole-company change is 12 percent more likely to be successful with continual communication from senior management. A video platform enables companies to help employees with their next steps after the company&8217;s change by offering webinars, and it helps HR keep track of who&8217;s actually attending them to ensure that employees are taking the right steps in the transition.
“The advantage of using video is that it keeps human element,&8221; says Frederickson. “If you have a well-planned message and deliver it with technology in a flawless and seamless way, it gives employees access to go get information they need.&8221;
Learn more about IBM Cloud Video solutions.
The post 3 key ways streaming video helps with delivering tough corporate news appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

10. Februar 201710. Februar 2017

da Agency

Cloud and cognitive technologies are transforming the future of retail

Though the retail industry is rapidly changing, one fact remains constant: the customer is king.
Some 35,000 attendees made their way to the National Retail Federation’s “Big Show” (NRF) at New York’s Javits Center last month for a first-hand look into the future of retail. Talk of digital transformation created buzz on and off the show floor.
Just south of the show at the IBM Bluemix Garage in Soho, some of the industry’s revolutionary leaders gathered for a roundtable discussion on how cloud and cognitive technologies are becoming an integral part of how retailers reach and meet shopper’s expectations.
Attendees included Staples CTO Faisal Masud; Shop Direct CIO Andy Wolfe; Retail Systems Research analyst Brian Kilcourse; Forbes retail and consumer trends contributor Barbara Thau; The New Stack journalist Darryl Taft; IBM Bluemix Garages Worldwide Director Shawn Murray; IBM Blockchain program director Eileen Lowry; and Pace University clinical professor of management and Entrepreneurship Lab director Bruce Bachenheimer. The group took a close look at how retailers experiment with new ways to give customers what they want and drive that transformation using cloud and cognitive computing.
Consumers drive tech adoption
Retail is a famously reactive business; it’s slow to adopt new technologies and innovation. However, in today’s consumer-driven age, retailers must quicken their pace, often setting aside internal strategies to tune into consumers’ demands and adopt the technology necessary to keep up.
Yet that’s often not the case. The IBM 2017 Customer Experience Index study found that 84 percent of retail brands offered no in-store mobile services and 79 percent did not give associates the ability to access a customer’s account information via a mobile device. These are key services for a seamless customer experience.
Retailers must capture the attention of consumers armed with smartphones and tablets. They are comparing product prices and reading reviews on social networks all the time. The hyper-connected consumer is the new norm, and understanding and engaging with them in real time is essential.
What customers really want
While retailers are busy selling, customer expectations are changing by the second. Retail is now about providing high-quality, engaging experiences.. Forward-thinking retailers use cloud infrastructure and AI-powered innovations such as cognitive chatbots to amplify and augment, not replace, the core human element of retail.
For example, for a retail recommendations strategy, Masud said that Watson Conversation on IBM Cloud helped Staples discover a gap between what the company assumed customers wanted and what they actually wanted. When Staples worked with IBM to develop its “Easy Button” virtual assistant, Masud said, “We thought we would just be making recommendations for more office supplies based on their purchases.”
What Staples found was that customers were also seeking solutions to help track administrative details in their office. “They wanted us to remember things for them like the catering company they used or the name of the person who signs for the delivery,” Masud said.
A cloud-powered, cognitive technology solution provides clear benefits for Staples. As it continues to learn customer orders and preferences, the office-supply-ordering tool continues to improve its predictive and order-recollection capability, making it more valuable to users for everyday tasks. Staples can bring the on-demand world to customers, allowing them to order anytime, anywhere and from any device.
“The one thing customers want is ease,” added Shop Direct CIO Andy Wolfe. He noted people want to easily shop online from whatever device or online channel they prefer. Shop Direct is the UK’s second largest pureplay digital retailer.
Retailers must have actionable insights derived from backend systems data such as supply chains, as well as the data that customers produce and share.
Shop Direct had a wealth of data, but needed to identify the most important information, which is why the company adopted IBM Watson and IBM Cloud. Shop Direct wanted to better understand customers and run its business more efficiently to meet shoppers’ needs.
Wolfe and his team were able to use the power of cloud and cognitive to mine and understand data, turning it into a resource to personalize the company’s retail product offerings and make brands even more affordable for customers.
The future of retail and technology
“There will always be retail,” said Brian Kilcourse, analyst at Retail Systems Research. “It will just be different.”
The nature of shopping is evolving from a purposeful trip to a store or a website toward the &8220;ubiquitous shopping era&8221;: shopping everywhere, by any means, all the time. This has created a significant challenge for retailers to create an operationally sustainable and engaging experience that inspires loyalty as customers hop from store to web to mobile to social and back again.
That’s where cognitive and cloud comes into play. Retailers can harness the power of data from their business and their customers to better personalize, contextualize and understand who customers are and offer them the products they want when they want them.
Timing and convenience are key for customers now. Cloud and cognitive technologies enable brands to authentically connect with consumers in an agile and scalable way. Cloud is no longer an IT trend. With apps, chatbots and new ways to reach customers, it is the platform keeping retailers available to consumers and in business.
Learn more about IBM Cloud retail solutions.
The post Cloud and cognitive technologies are transforming the future of retail appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

8. Februar 20178. Februar 2017

da Agency

Watson, what should I watch tonight?

The world is consuming an amazing amount of streaming video content.
From silly internet videos to binge watching hours of the latest trending show, the average person’s appetite for streaming video content is tremendous. By 2021, the research firm MarketsandMarkets expects the market to reach $70 billion. To compete in this increasingly crowded space, providers must find a way to differentiate themselves to keep subscribers engaged and actively paying subscriber fees.
There’s a simple method for reducing churn while engaging and pleasing viewers: providers must understand, at a deep level, what individual subscribers want to watch and point them directly to that content. This highly personalized approach to serving up streaming video content becomes possible when providers add machine-learning technologies such as IBM Watson to their streaming services.
Stop subscriber attrition with in-platform cognitive capabilities
IBM Watson can find patterns in the way people interact with video content, from the selections they make, to how often they rewind or pause, to which videos they have abandoned midstream or watched repeatedly. By identifying and analyzing commonalities between the types of programming a viewer enjoys, Watson can suggest options the viewer might not have even considered.
Today, a viewer&8217;s search for video content typically only involves basic metadata, such as the title, genre, and so on. However, Watson can amass advanced metadata about what happens inside streaming videos. It can index and catalog at a much deeper level. This includes the ability to index spoken word, visual imaging, tone and much more.
These capabilities enable subscribers to interact with content in entirely new ways. In the future, a viewer could say, “Show me a movie to help me sleep,” or “Show me a move where people overcome difficult challenges,” and the library could bring up videos that help a subscriber’s mood or outlook in a new way.
A smarter way to plan a video content strategy
Watson collects viewer data from video platforms over time and combines that data from other sources such as social channels, third-party reviews, global trends, and other content including geospatial and real-time weather information. As that happens, providers can compile data-rich profiles of individual subscribers and proactively predict targeted and highly relevant content recommendations.
Watson&8217;s capabilities can also help providers identify users who are likely to drop off their platforms so they can take steps to prevent that from happening. For example, if customers who enjoy watching romantic comedies are particularly prone to churn, the provider can examine its current offerings and decide if it should license more movies. Or it might find that it has a wide range of similar content that would appeal to this segment of subscribers it could recommend instead.
The opportunities that this technology will uncover in improving customer experience and recommendation success on a video streaming platform are limitless. In a future blog, I will explore how cognitive systems can help with areas such as content acquisition and creation, marketing strategies, advertising intelligence, and general business decision making.
Learn more about IBM Cloud Video.
The post Watson, what should I watch tonight? appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

3. Februar 20173. Februar 2017

da Agency

6 do-not-miss hybrid cloud sessions at IBM InterConnect

Are you looking at expanding your private or hybrid cloud? Or maybe you want to get the most out of your current capabilities? Whatever your goals are, you can’t afford to miss these six exciting sessions at IBM InterConnect 2017.
1. Session #2207: Strategies for successfully enabling BPM/ODM in the hybrid cloud
How do you achieve maximum business value in a cloud environment? Learn how to harness the capabilities of hybrid cloud to deploy, implement and manage enterprise workloads like IBM Business Process Manager (BPM) and IBM Operational Decision Manager (ODM). Come learn the business requirements you need to consider when working with application performance, servers, business processes, financial objectives, service management, disaster recovery, infrastructure, risk management and hybrid cloud integration.
2. Session #5992: Bluemix local system: Cloud adoption for enterprise IT
It can be expensive to deliver the right applications to the right users at the right time. IBM technical experts will share how IBM Bluemix Local System and IBM PureApplication can help accelerate and optimize your IT operations with a turnkey, integrated private cloud application platform. See how you can run both traditional and cloud-based applications while supporting open technology through built-in automation for simple and repeatable application environment deployments.
3. Session #6017: Strategies for high availability and disaster recovery with private cloud
Every organization has its own high availability (HA) and disaster recovery (DR) requirements. IBM Bluemix Local System and IBM PureApplication provide many capabilities that allow you to implement HA strategies and DR scenarios for your applications and data. Join this roundtable discussion to share your feedback and learn best practices from IBM and your peers.
4. Session #1326: Total economic value from AXA’s PureApplication implementation
Launching new insurance products often means high upfront costs and time-consuming processes for setting up infrastructure. Learn how AXA Technology Services implemented a new underwriting process for household products on a pilot using IBM PureApplication Service in the cloud. You’ll also hear how it performed a proof of concept using PureApplication System in its data center. Both projects succeeded, and AXA Belgium purchased two IBM PureApplication System units for its on-premises use. Read the case study to see the total value of what was accomplished, and attend the session to see how you might be able to do the same.
5. Session #3766: Habib Bank Limited&8217;s journey to platform as a service with IBM PureApplication System
Do you want to learn how your organization might streamline application delivery and reduce costs? Habib Bank will share its journey from traditional IT to a new cloud-based platform as a service (PaaS) solution with IBM PureApplication and WebSphere Application Portal. Hear how this transition helped the company deploy its applications 300 percent faster and save USD 500,000.
6. Session #4189: Enterprise IT modernization at 1-800-FLOWERS
Do you want to learn how to modernize your business to meet new challenges? 1-800-FLOWERS has reinvented itself several times since its founding as a local florist in 1976. The company has gone from local retail to global telephone sales, and now it is on the leading edge of the DevOps revolution. Learn how 1-800-FLOWERS uses IBM PureApplication Software as part of its enterprise modernization and DevOps automation process to greatly improve provisioning times for new development, test and production environments. You&8217;ll also discover how patterns changed the company’s vocabulary from “months” to &8220;days.&8221;
These are just some of the many exciting sessions at InterConnect. If you’re still not signed up, register today, and then add these six sessions to your schedule. Don’t miss the opportunity to talk directly with our executives and technical teams by stopping by the InterConnect 2017 EXPO. I look forward to seeing you there.
The post 6 do-not-miss hybrid cloud sessions at IBM InterConnect appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

31. Januar 201731. Januar 2017

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

29. Januar 201729. Januar 2017

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 – 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 …
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 “resource island” 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