technology News, Entwicklungen, Updates, HowTos - Seite 288 von 296

This week we released the latest version of our OpenStack product, Red Hat OpenStack Platform 9. This release contains more than 500 downstream enhancements, bug fixes, documentation changes, and security updates. It’s based on the upstream OpenStack Mitaka release. We have worked hard to reduce the time to release new versions and have successfully done so with this release! Red Hat OpenStack Platform 9 contains new Mitaka features and functionality, as well as the additional hardening, stability, and certifications Red Hat is known for. Of course, there continues to be tight integration with other key portfolio products, as well as comprehensive documentation.
So what are some of the main new highlights for this release?

Automated updates and upgrades
Red Hat OpenStack Platform director 9 provides backward compatibility 1 version back. This means you can use director 9 to deploy and manage Red Hat OpenStack Platform 8. And starting with version 9, the lifecycle support for director has been increased to match the lifecycle support for the core.
When you decide it’s time to upgrade, director will perform the required actions step-by-step. One of these steps will involve the enablement of the new alarms API (called Aodh–more on that later) and the migration of the old Ceilometer Alarms.
Heat resource chains and a new hook for pre-delete
Previously, customers using Heat could only specify a single monolithic template for orchestration. Now multiple templates can be supported simultaneously. This simplifies the use of Heat templates and provides greater flexibility.
Also new in version 9, Heat can perform cleanup actions, like closing network connections, logging and event, or syncing filesystems. This allow for proper shutdown of virtual machines managed by Heat.
Live migration improvements
Compute now automatically detects block vs. shared storage when performing the live migration of an instance, which can accelerate the process by leveraging the shared storage. It’s also now possible to monitor the live migration progress and even pause or cancel a virtual machine in the middle of the migration from the old to the new hypervisor.
Thread-aware CPU pinning for NFV and HPC workloads
Earlier releases of Compute added support for instances with dedicated CPU resources and NUMA topology awareness. By default, it would prefer using sibling threads for vCPUs using simultaneous multi-threading (SMT), although its behavior could only be changed cluster-wide with the configuration file options. Now that behavior is configurable dynamically within individual image properties and extra specifications.

Prefer: the default, it prefers placing guest vCPUs on sibling threads where they are available. Host may or may not have SMT support.
Isolate: this isolates threads placing guest vCPUs on different physical cores. On systems with SMT support, it means that no vCPUs from other guests are placed on those cores.
Require: this forces the use of thread siblings. The host must have SMT support.

Ability to purge a project’s networking
Previously, after deleting a project, you had to deal with stale resources that were once allocated to the project. This included networks, routers, and ports. These stale resources had to be manually deleted and deleted in the correct order. Red Hat OpenStack Platform 9 has addressed this issue using the Neutron purge command to delete the Neutron resources that once belonged to a particular project.
This reduces the possibility of orphaned resources (IPs, ports, and DHCP servers) living in the system without an owner and possibly unnecessarily consuming resources. Previously, only the admin could see and clean them either manually or with scripts. Now the admin (after deleting the tenant) can remove the networking artifacts in a coherent fashion. No more wasting resources, like floating IPv4 addresses, after removing a project.
Gnocchi
Gnocchi is a time-series backend for ceilometer that works with Ceph or Swift and provides high performance storage and queries of the metrics collected, which is highly scalable and better than previous implementations. With Red Hat OpenStack Platform 9, Gnocchi is promoted from “tech preview” to “fully supported”, but it will not deploy by default by Director&8211;it needs to be enabled by the operator.
Aodh
The new Alarming component that replaces Ceilometer Alarms is called Aodh (pronounced like the letter “A”). It offers a separate API for configuring and triggering custom Alarms by tenants. Director’s installation tool will enable Aodh and migrate users to the new API.
These are some of the main highlights for product features. As a reminder to our customers, Red Hat Cloudforms is included free of charge with Red Hat OpenStack Platform (quickstart documentation available here), to manage both infrastructure and running workloads. And for version 9, Red Hat CloudForms offers the following new features:

Tenant Management: SSH Key Management, Volume and Images Management, Right Size Recommendations for CPU and Memory, Instance Flavor Reconfiguration (i.e. from m1.tiny to m2.xlarge), Live Migration, Events from Ceilometer, etc.
Infrastructure management (undercloud): Scale In and Out (add or remove overcloud nodes), evacuate all or selected instances from a host that needs to be decommissioned; Also, the ability to do Capacity Planning to evaluate how many VMs of a particular profile (e.g. currently running on VMware) can fit on our OpenStack deployment.

Ready to learn more?
Check out our Red Hat OpenStack Platform page, where you can request a free 60-day trial). Or visit our customer portal, where you can:

View the list of supported components and certified plug-ins
Browse the official documentation page
Check out the version 9 release notes

Quelle: RedHat Stack

2. September 20162. September 2016

da Agency

Six reasons OpenStack fails (Hint: it’s not the technology)

The post Six reasons OpenStack fails (Hint: it’s not the technology) appeared first on Mirantis | The Pure Play OpenStack Company.
We know OpenStack is hard. But why?
Earlier this month, Christian Carrasco gave a keynote address at the OpenStack Days Silicon Valley conference, discussing six factors behind OpenStack evaluation and deployment failure — and how to solve those problems. As Cloud Advisor at Tapjoy, Carrasco is architecting a 550-million-user cloud based on both private and public resources. He also has a history as CTO of a private cloud hardware company and two other startups focused on cloud technologies, so he brought a lot of insight into the causes of failure, pinpointing six primary points of failure.
Lesson 1: Leave the dogma at home
Dogmatic views, or beliefs accepted as fact without doubt, are blinders, he explained, and they can come from a variety of sources, including bad previous experiences with technology. For example, Carrasco’s experience with OpenStack five years earlier had been a negative experience because the platform just wasn’t ready. Fast-forward five years to 2016, and it’s now rock-solid for many applications, including his.
However, if dogma had prevailed, trying OpenStack again might have been out of the running. Keep in mind, though, that rebranding old technology as new, or new technology as old, or even rebranding fake technology as its legitimate counterpart can lead to a poor experience that gets associated with that real technology. (See Lesson 5.)
Lesson 2: Fear, doubt, uncertainty, and doom (aka FUDD) can cause problems
Remember when Linux was first launched? If you do, then you probably also remember the a proliferation of scare tactics. Your world will end if you use Linux! Nothing will work! Licensing is too confusing! Cats and dogs, living together, total chaos!
OpenStack has seen the same kind of FUDD. Every year, independent publications, public entities, and skewed statistical reports predict the death of OpenStack. And yet, OpenStack keeps on keeping on, taking over the private cloud market.
Lesson 3: Find the right distribution
The third reason Carrasco covered was the “You picked the wrong trunk” scenario. The latest version of open source software such as OpenStack is called the “trunk”, a base repository of code. The thing about trunk is that it requires lots of tweaking and the modules aren’t always in tune with each other. Community Linux trunks can have some configurations tweaked but not all, and it still requires a level of expertise, so deploying from trunk is not for less-experienced engineers.
Lesson 4: You are not a full-stack engineer
In today&8217;s world, where personnel often have to fulfill multiple roles, many engineers are being told they have to be &8220;full-stack engineers.&8221;
Carrasco, who has worked the full stack and still says he’s not a full-stack engineer, believes full-stack engineers are myths, and he makes a great argument for his belief. It’s really hard to be a full-stack engineer, he says, because you have to be proficient in every realm of the stack &8212; and it&8217;s not just the software. Just being proficient in software stack is difficult, but when you throw in the hardware side, as well as networking, security, and so on, being an expert in everything is a monumental, if not impossible, task.
Organizations need to be aware of the skillset of the people leading the OpenStack deployment and be sure they&8217;ve got all of their bases covered.
Lesson 5: You thought OpenStack was a better buggy for your horse
OpenStack isn’t necessarily a better buggy, or a cheaper method of doing something, or the open source way of doing something. Carrasco says it’s more of a paradigm shift, a new methodology that is still evolving, in the way data centers operate. And the reality is that sometimes this methodology isn’t ideal for traditional businesses.
Lesson 6: You didn&8217;t have a sufficient team
While the rumotrs that you need dozens of experts to successfully deploy OpenStack is an exaggeration, you&8217;re likely going to have problems if you try to deployed it alone, or with a very small team that isn&8217;t ready to deploy data center technology.
If you need help with your OpenStack deployment, there are plenty of options available for design, architecture, and verification of your stack, from automated tools to semi- and fully-managed services.
Along the same lines, some companies aren’t really ready for OpenStack yet, and it may not be economically feasible for a small company to hire a cloud team, purchase hardware, and rack up costs.
On the other hand, some companies lend themselves well to deployment, such as companies that were born online, are making the move to online, or are ready to stop using buggies and be committed and engaged to moving to the next generation of #cloud computing.
OK, so what do I do about it?
Carrasco offers two major solutions to help prevent OpenStack deployment failure.
The first thing Carrasco asks companies he advises is &8220;Where is your Cloud Officer?&8221; If you’ve made a multi-million dollar investment in your cloud and it’s a side project of some other team in your company, that&8217;s not a recipe for success. “What happens to clouds that become orphaned?” he asks. “They become security risks. They become a headache. Nobody wants to work with them, and they vanish,&8221; he says. There needs to be real ownership for your cloud to succeed, and a Cloud Officer will protect your cloud, prevent vendor lock-in, and bring the cloud in line with the organization’s initiatives.
The second solution he suggested is all about vendors. Despite the open nature and coopetition of OpenStack, according to Carrasco, the status quo consists of both public and private vendors fiercely guarding their territory and coming up with creative ways to lock users into their service or their cloud technology, etc., and few companies are creating ways to enable outside operability.
Carrasco’s ultimate vision for a solution is to adopt what he calls a hyper-converged cloud. In this architecture, you have your cloud and your assets powered by multiple vendors &8212; whoever you want to choose to power your cloud. This structure has an added advantage of opening possibilities for niche providers of services not offered by private or public clouds.
The point is not about technology, but about people being able to own their assets. Carrasco is instituting this concept successfully now at Tapjoy, but for this concept to work, interoperability standards are key. Oh, and to those who’d say it’s late for standards, Carrasco points to market research that shows cloud technology is still a tiny speck on the radar when compared to the market share of other tech industries.
So stop trying to make a better buggy, Carrasco says, and focus on making the next-generation cloud.
You can see the entire speech on the OpenStack Days Silicon Valley website.
The post Six reasons OpenStack fails (Hint: it&8217;s not the technology) appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis