If you are using Red Hat Enterprise Linux (RHEL), you can use Red Hat Insights to find out what systems are exposed, and to what extent. See how to find and remediate security vulnerabilities faster using Insights.
Quelle: CloudForms
The Friday Five is a weekly Red Hat® blog post with 5 of the week’s top news items and ideas from or about Red Hat and the technology industry. Consider it your weekly digest of things that caught our eye.
Quelle: CloudForms
For users on our Business and eCommerce Plans, plugins are a critical part of the WordPress.com experience. We’re always looking for ways to simplify the process of discovering and installing powerful WordPress plugins.
As a result, we’re now making it possible to purchase certain plugins directly on the WordPress.com plugin page. Not only that, but WordPress.com will offer monthly and annual plugin pricing which provides site owners more flexibility.
Initially, you can purchase six of our most popular WooCommerce plugins on the WordPress.com plugins page.
WooCommerce Subscriptions — Allow customers to subscribe to your products or services and pay on a weekly, monthly or annual basis.WooCommerce Bookings — Allow customers to book appointments, make reservations or rent equipment without leaving your site.WooCommerce Table Rate Shipping — Advanced, flexible shipping. Define multiple shipping rates based on location, price, weight, shipping class or item count.WooCommerce AutomateWoo — Powerful marketing automation for WooCommerce. AutomateWoo has the tools you need to grow your store and make more money.WooCommerce Shipment Tracking — Add shipment tracking information to your orders.WooCommerce Xero — Save time with automated sync between WooCommerce and your Xero account.
Purchasing a plugin via the new WordPress.com interface is simple. On the plugins page, click on one of the paid plugin cards to be redirected to a detailed product listing page. When you’re ready, click the purchase button in the top right of the product listing page. Your purchase won’t be final until you confirm your payment method and details on the following page. The plugin will be installed automatically.
This announcement is just the start — look for more paid plugins and other exciting updates over the coming months. Let us know in the comments below what plugins you would like to see available for purchase directly on WordPress.com.
Stay tuned and click here to begin exploring plugins now!
As a reminder, all plugins (free or paid) are currently only available to customers with a WordPress.com Business or eCommerce Plan. If you’re interested in purchasing or upgrading to an annual Business Plan, click here for a 25% discount off your first year.
Promo code: PLUGINSBLOG25
Quelle: RedHat Stack
Quelle: Mirantis
Every month, Mirantis sends out a newsletter chronicling top industry and company news. Below you’ll find links to blogs, tutorials, videos, and the latest updates to our enterprise, open source, and training offerings. If you don’t currently receive the newsletter, you can subscribe by clicking the button on the top right. Mirantis Brings Secure Registries … Continued
Quelle: Mirantis
Enterprises face the challenge of consistently deploying and managing applications in production, at scale. Fortunately, there are more technologies and tools available today than ever before. However, transitioning from a traditional, monolithic architecture to a cloud native one comes with its own unique challenges. Below, you will find a list of the critical first steps … Continued
Quelle: Mirantis
RDO Xena Released
The RDO community is pleased to announce the general availability of the RDO build for OpenStack Xena for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Xena is the 24th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world.
The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-xena/.
The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds.
All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first.
PLEASE NOTE: RDO Xena provides packages for CentOS Stream 8 only. Please use the Victoria release for CentOS Linux 8 which will reach End Of Life (EOL) on December 31st, 2021 (https://www.centos.org/centos-linux-eol/).
Interesting things in the Xena release include:
The python-oslo-limit package has been added to RDO. This is the limit enforcement library which assists with quota calculation. Its aim is to provide support for quota enforcement across all OpenStack services.
The glance-tempest-plugin package has been added to RDO. This package provides a set of functional tests to validate Glance using the Tempest framework.
TripleO has been moved to an independent release model (see section TripleO in the RDO Xena release).
The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/xena/highlights.html
TripleO in the RDO Xena release:
In the Xena development cycle, TripleO has moved to an Independent release model (https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-independent-release.html) and will only maintain branches for selected OpenStack releases. In the case of Xena, TripleO will not support the Xena release. For TripleO users in RDO, this means that:
RDO Xena will include packages for TripleO tested at OpenStack Xena GA time.
Those packages will not be updated during the entire Xena maintenance cycle.
RDO will not be able to included patches required to fix bugs in TripleO on RDO Xena.
The lifecycle for the non-TripleO packages will follow the code merged and tested in upstream stable/Xena branches.
There will not be any TripleO Xena container images built/pushed, so interested users will have to do their own container builds when deploying Xena.
You can find details about this on the RDO webpage
Contributors
During the Xena cycle, we saw the following new RDO contributors:
Chris Sibbitt
Gregory Thiemonge
Julia Kreger
Leif Madsen
Welcome to all of you and Thank You So Much for participating!
But we wouldn’t want to overlook anyone. A super massive Thank You to all 41 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories:
Alan Bishop
Alan Pevec
Alex Schultz
Alfredo Moralejo
Amy Marrich (spotz)
Bogdan Dobrelya
Chandan Kumar
Chris Sibbitt
Damien Ciabrini
Dmitry Tantsur
Eric Harney
Gaël Chamoulaud
Giulio Fidente
Goutham Pacha Ravi
Gregory Thiemonge
Grzegorz Grasza
Harald Jensas
James Slagle
Javier Peña
Jiri Podivin
Joel Capitao
Jon Schlueter
Julia Kreger
Lee Yarwood
Leif Madsen
Luigi Toscano
Marios Andreou
Mark McClain
Martin Kopec
Mathieu Bultel
Matthias Runge
Michele Baldessari
Pranali Deore
Rabi Mishra
Riccardo Pittau
Sagi Shnaidman
Sławek Kapłoński
Steve Baker
Takashi Kajinami
Wes Hayutin
Yatin Karel
The Next Release Cycle
At the end of one release, focus shifts immediately to the next release i.e Yoga.
Get Started
To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works.
Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world.
Get Help
The RDO Project has our users@lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev@lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org.
The #rdo channel on OFTC IRC is also an excellent place to find and give help.
We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel in Libera.Chat network, and #tripleo on OFTC), however we have a more focused audience within the RDO venues.
Get Involved
To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation.
Join us in #rdo and #tripleo on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.
Quelle: RDO
In November 2021, we announced the general availability of Tau VMs. Since then, Google Cloud’s Tau VMs with Google Kubernetes Engine (GKE) have unlocked value for many customers who are now using Tau VMs for their production workloads, such as: Ascend, who achieved over 125% higher performance; Nylas, who gained over 40% higher price-performance; and OpenX, who achieved 40% better price-performance while at the same time reducing their application latency by 62%. T2D is the first instance type in the Tau VM family and is built on the latest 3rd generation AMD EPYCTM processors, offering 42% higher price-performance compared to general-purpose VMs from any of the leading public cloud vendors. Tau VMs offer a leading combination of performance, price, and full x86 compatibility, offering customers the lowest cost solution for scale-out workloads. Tau VMs are available in predefined shapes, with up to 60vCPUs per VM, 4GB of memory per vCPU, networking up to 32 Gbps and a slew of storage options including Standard, Balanced and Performance PD. Tau VMs are also available as Spot VMs, offering an over 60% discount compared to on-demand pricing. For customers looking for advanced container orchestration, GKE delivers high levels of reliability, security, and scalability, and has supported Tau VMs since the day they became available on Google Cloud. Tau VMs are ideal for CPU-bound workloads such as web-serving with encryption, video encoding, compression/decompression, image processing and horizontally-scaled applications. Using Tau VMs along with GKE’s cost-optimization best practices can help lower your total cost of ownership. You can add Tau VMs to new or existing GKE clusters by specifying the Tau T2D machine type in your GKE node-pools through the Cloud console or by using –machine-type in gcloud. Here is what some of our customers have to say about Tau VMs:Ascend provides a unified analytics and data engineering platform, and chose Tau VMs along with GKE to run their data-intensive workload — primarily because of Tau’s absolute performance and price-performance advantage.“Our core capability at Ascend is bringing together data ingestion, transformation, delivery, orchestration and observability into a single platform. To operate at scale and keep pace with our telemetry data production rates, high single-threaded performance is critical. With Google Cloud’s Tau VMs with Google Kubernetes Engine (GKE), we are able to achieve over 125% higher performance than previous generation families. This has completely changed our ability to query historical metrics. Where previously metric queries against historical data over ranges longer than a couple hours were difficult, we can now easily query data ranges of multiple weeks.” – Joe Stevens, Tech Lead – Infrastructure, Ascend.ioNylas is a pioneer and leading provider of productivity infrastructure solutions for modern software. In the past year, Nylas has been using GKE in their journey to reinvent their architecture and provide their enterprise customers with a bi-directional universal email sync, security compliance with the highest enterprise standards, and industry-specific machine learning services. “For our core application, Google’s Tau VMs with Google Kubernetes Engine delivers over 40% better price-performance than Amazon’s Graviton-based VMs. Further, Tau VMs maintain x86 compatibility and eliminate the need to maintain a separate stack for ARM. We are moving our workload from Amazon Web Services to Google Cloud to take advantage of these benefits.” – David Ting, SVP of Engineering, NylasOpenX operates an independent ad exchange. Operating 100% on Google Cloud has enabled OpenX to achieve improved performance, scalability, speed and global reach. “At OpenX, our ad-exchange services over 200 billion requests every day. Getting the best combination of performance and price from the infrastructure is critically important for us. We use multiple Google Kubernetes Engine (GKE) clusters across geographic regions with autoscaling to power our ad-delivery components. Running Google Cloud’s Tau VMs with GKE has enabled over 40% better price-performance and 62% latency reduction for our application as compared to the prior generation family. We have made the move to Tau VMs for our application to take advantage of these benefits.” – Paul T.Ryan, CTO, OpenXWe are excited to see Tau VMs adding value for so many of our customers by enabling industry leading price-performance for a variety of workloads. If you haven’t tried Tau VMs yet, give them a try today in our Iowa, Netherlands and Singapore regions and move your production workloads to Tau VMs. Tau VMs will be arriving in additional regions and zones in the coming weeks. You can provision GKE node pools based on Tau VMs and explore how you can take advantage of improved price-performance for your scale-out containerized workloads. To get started, go to the Google Cloud Console, select Google Kubernetes Engine, and choose Tau T2D for your GKE nodes. To learn more about Tau VMs or other Compute Engine VM options, check out our machine types and our pricing pages.Related ArticleTau T2D VMs now in Preview: Independent testing validates market-leading price-performanceT2D VMs powered by 3rd Generation AMD EPYC processors (code-named Milan) are now available for the Compute Engine Tau family in preview.Read Article
Quelle: Google Cloud Platform
Cloud Bigtable is a fully managed service that can swiftly scale to meet performance and storage demands with the click of a button. If you’re currently using Bigtable, you might configure your cluster sizes to perform for peak throughput or programmatically scale to match your workload. Bigtable now supports autoscaling for improved manageability, and in one of our experiments autoscaling reduced costs of a common diurnal workload by over 40%.You only pay for what you need when autoscaling is enabled; Bigtable will automatically add or remove capacity in response to the changing demands of your workloads. Autoscaling enables you to spend more time on your business and less time managing your infrastructure due to the reduced overhead of capacity provisioning management. Autoscaling works on both HDD and SSD clusters, and is available in all Bigtable regions.We’ll look at when and how to use this feature, go through a performance analysis of autoscaling in action, and finally see how it can impact your database costs.Enabling AutoscalingCloud Bigtable autoscaling is configured at the cluster level and can be enabled using the Cloud Console, the gcloud command-line tool, the Cloud Bigtable Admin API, and Bigtable client libraries.With autoscaling enabled, Bigtable automatically scales the number of nodes in a cluster in response to changing capacity utilization. The business-critical risks associated with incorrect capacity estimates are significantly lowered: over-provisioning (unnecessary cost) and under-provisioning (missing business opportunities).Autoscaling can be enabled for existing clusters or configured with new clusters. You’ll need two pieces of information: a target CPU utilization and a range to keep your node count within. No complex calculations, programming, or maintenance are needed. One constraint to be aware of is the maximum node count in your range cannot be more than 10 times the minimum node count. Storage utilization is a factor in autoscaling, but the targets for storage utilization are set by Bigtable and not configurable. Below are examples showing how to use the Cloud Console and gcloud to enable autoscaling. These are the fastest ways to get started.Using Cloud ConsoleWhen creating or updating an instance via the Cloud Console you can choose between manual node allocation or autoscaling. When autoscaling is selected, you configure your node range and CPU utilization target.Using command lineTo configure autoscaling via the gcloud command-line tool, modify the autoscaling parameters when creating or updating your cluster as shown below.Updating an existing cluster:Creating a new cluster:Transparency and trustOn the Bigtable team, we performed numerous experiments to ensure that autoscaling performs well with our customers’ common workloads. It’s important that you have insight into Cloud Bigtable’s autoscaling performance, so you can monitor your clusters and understand why they are scaling. We provide comprehensive monitoring and audit logging to ensure you have a clear understanding of Bigtable’s actions. You’re able to connect Bigtable activity to your billing and performance expectations and fine tune the autoscaling configuration in order to ensure your performance expectations are maintained. Below is the Bigtable cluster monitoring page with graphs for metrics and logs for the cluster.Related ArticleCloud Bigtable launches Autoscaling plus new features for optimizing costs and improved manageabilityCloud Bigtable launches autoscaling that automatically adds or removes capacity in response to the changing demand for your applications.Read ArticleWhen is autoscaling right for your workload?Bigtable is flexible for a variety of use cases with dynamic traffic profiles. Bigtable autoscaling may not always be the right configuration for your business, so here are some guidelines for when autoscaling is ideal.When to use autoscalingYou’re an existing Bigtable user who wants to optimize costs, while maintaining performance for your cluster. For example: diurnal traffic patterns that you might see with online retail.You’re a new Bigtable user or have a new workload. Provisioning enough capacity to meet unknown use cases is hard.Your business is growing, and you’re not sure the extent of future growth. You want to be prepared to scale for any opportunity.What autoscaling won’t solveCertain batch workloads. Autoscaling will react to a sharp increase in traffic (a “step” or batch upload of data). However, Bigtable will still need to rebalance the data and traffic against a rapid increase in nodes, and this may cause a performance impact as Bigtable works to rebalance. Autoscaling is likely not the correct solution to resolving hotspotting or ‘hot tablets’ in your Bigtable cluster. In these scenarios it is best to review data access patterns and row key / schema design considerations.Autoscaling in ActionCloud Bigtable’s horizontal scalability is a core feature, derived from the separation of compute and storage. Updating the number of nodes for a Bigtable instance is fast whether or not you use autoscaling. When you add nodes to your cluster, Bigtable rebalances your data across the additional nodes, thus improving the overall performance of the cluster. When you scale down your cluster, Bigtable rebalances the load from the removed nodes to the remaining nodes.With autoscaling enabled, Bigtable monitors the cluster’s utilization target metrics and reacts in real time to scale for the workload as needed. Part of the efficiency of Bigtable’s native autoscaling solution is that it connects directly to the cluster’s tablet servers to monitor metrics, so any necessary autoscaling actions can be done rapidly. Bigtable then adds or removes nodes based on the configured utilization targets. Bigtable’s autoscaling logic scales up quickly to match increased load, but scales down slowly in order to avoid putting too much pressure on the remaining nodes.Example workloadLet’s look at one of the experiments we ran to ensure that autoscaling performance was optimal in a variety of scenarios. The scenario for our experiment is a typical diurnal traffic pattern: active users during peak times and a significant decrease during off-peak times. We simulated this by creating a Bigtable instance with 30 GB of data per node and performed point reads of 1 kb. We’ll get some insights from this experiment using Bigtable’s monitoring graphs. You can access the cluster’s monitoring graphs by clicking on the cluster ID from the Bigtable instance overview page in the Cloud Console.Bigtable Instance overview page in Cloud ConsoleHaving clicked through to the cluster overview page, you can see the cluster’s node and CPU utilization monitoring graphs as seen below. Bigtable cluster overview page in the Cloud ConsoleThe node count graph shows a change from 3 nodes to 27 nodes and back down to 3 nodes over a period of 12 hours. The graph shows the minimum and maximum node counts configured as well as the recommended number of nodes for your current CPU load, so you can easily check that those are aligned. The recommended number of nodes for CPU target (orange line) is closely aligned with the actual number of nodes (blue line) as CPU utilization increases, since scaling up happens quickly to keep up with throughput. As CPU utilization decreases, the actual number of nodes lags behind the recommended number of nodes. This is in line with the Bigtable autoscaling policy to scale down more conservatively to avoid putting too much pressure on the remaining nodes. In the CPU utilization graph we see a sawtooth pattern. As it reaches a peak, we can compare both graphs to see the number of nodes is adjusted to maintain the CPU utilization target. As expected, CPU utilization drops when Bigtable adds nodes and steeply increases when nodes are removed. In this example (a typical diurnal traffic pattern), the throughput is always increasing or decreasing. For a different workload, such as one where your throughput changes and then holds at a rate, you would see more consistent CPU utilization. On the cluster overview page, we are also able to see the logs and understand when the nodes are changing and why.Logs on the Bigtable cluster overview page in the Cloud ConsoleTo get more insights, you can go to the instance monitoring view. Here we can see even more graphs showing the experiment workload activity. Note the diurnal traffic pattern mentioned above is in line with autoscaling behavior: as throughput increases, node count increases and as throughput decreases, node count decreases.Bigtable Instance overview page in the Cloud ConsoleCost evaluationCustom dashboard in the Cloud Console Metrics Explorer showing node count average, node count, and read throughputThis experiment workload ran for 12 hours. Let’s see how the costs would change for this scenario with and without autoscaling. Assume a Bigtable node cost1 of $0.65/hr per nodeComparing the number of nodes and cost when using autoscaling vs scaling for peak: 15.84 nodes on average for autoscaling / 27 nodes scaled for peak = .587The number of nodes required is 58.7% of the peak when using autoscaling in this scenario. This is a potential approximate cost saving of 41.3% when using Bigtable native autoscaling in this example.These savings can be significant when you’re working with large amounts of data and queries per second. SummaryAutoscaling with Bigtable provides a managed way to keep your node count and costs aligned with your throughput. Get started: Enable autoscaling via the Cloud Console or command line.Check performance: Keep an eye on your latency with the Bigtable monitoring tools and adjust your node range.Reduce costs: While maintaining a 60% CPU utilization in our example scenario, the new cost on the diurnal workload was 58.7% of the total when compared to scaling for peak.1. See Bigtable pricing: https://cloud.google.com/bigtable/pricing2. ‘Scale for peak’ is the provisioning policy adopted by many DB operational managers to ensure the peak load is supported.
Quelle: Google Cloud Platform
Cloud Bigtable is a fully managed, scalable NoSQL database service for large operational and analytical workloads used by leading businesses across industries, such as The Home Depot, Equifax, and Twitter. Bigtable has more than 10 Exabytes of data under management and processes more than 5 billion requests per second at peak. Today, we’re announcing the general availability of autoscaling for Bigtable that automatically adds or removes capacity in response to the changing demand for your applications. With autoscaling, you only pay for what you need and you can spend more time on your business instead of managing infrastructure. In addition to autoscaling, we recently launched new capabilities for Bigtable that reduce cost and management overhead:2X storage limit that lets you store more data for less, particularly valuable for storage optimized workloads.Cluster groups provide flexibility for determining how you route your application traffic to ensure a great experience for your customers. More granular utilization metrics improve observability, faster troubleshooting and workload management. Let’s discuss these capabilities in more detail. Optimize costs and improve manageability with autoscalingThe speed of digitization has increased in most aspects of life driving up consumption of digital experiences. The ability to scale up and scale down applications to quickly respond to shifts in customer demand is now more critical for businesses than ever before. Autoscaling for Bigtable automatically scales the number of nodes in a cluster up or down according to the changing demands of usage. It significantly lowers your risk of over-provisioning and incurring unnecessary costs, and under-provisioning which can lead to missed business opportunities. Bigtable now natively supports autoscaling with direct access to the Bigtable servers to provide a highly responsive autoscaling solution.Customers are able to set up an autoscaling configuration for their Bigtable clusters using the Cloud Console, gcloud, the Bigtable admin API, or our client libraries. It works on both HDD and SSD clusters, and is available in all Bigtable regions. You can set the minimum and maximum number of nodes for your Bigtable autoscaling configuration in Cloud Console as shown below.Once you have set up autoscaling, it is helpful to understand what autoscaling is doing, when and why to reconcile against billing and performance expectations. We have invested significantly in comprehensive monitoring and audit logging to provide developers with granular metrics and pre-built charts that explain how autoscaling makes decisions.Related ArticleBigtable Autoscaling: Deep dive and cost saving analysisBigtable now supports autoscaling. In this post we’ll look at when and how to use it, analyze autoscaling in action, and see its impact o…Read Article2X the storage limit Data is being generated at a tremendous pace and numerous applications need access to that data to deliver superior customer experiences.Many data pipelines supporting these applications require high throughput, and low latency access to vast amounts of data while maintaining the cost of compute resources. In order to meet the needs of storage driven workloads, Bigtable has doubled the storage capacity per node so that you can store more data for less, and don’t have to compromise on your data needs. Bigtable nodes now support 5TB per node (up from 2.5TB) for SSD and 16TB per node (up from 8TB) for HDD. This is especially cost-effective for batch workloads that operate on large amounts of data. Manageability at scale with cluster groupsBusinesses today need to serve users across regions and continents and ensure they provide the best experience to every user no matter the location. We recently launched the capability to deploy a Bigtable instance in up to 8 regions so that you can place the data as close to the end user as possible. A greater number of regions helps ensure your applications are performant for a consistent customer experience, where your customers are located. Previously, an instance was limited to four regions.With a global presence, there are typically multiple applications that require access to the replicated data. Each application needs to ensure that its serving path traffic does not see increased latency or reduced throughput because of a potential ‘noisy neighbor’ when additional workloads need access to the data. To provide improved workload management, we recently launched App Profile Cluster Group routing. Cluster group routing provides finer grained workload isolation management, allowing you to configure where to route your application traffic. This will allow you to allocate Bigtable clusters to handle certain traffic like batch workloads while not directly impacting the clusters being used to serve your customers.Greater observabilityHaving detailed insight and understanding of how your Bigtable resources are being utilized to support your business is crucial for troubleshooting and optimizing resource allocation. The recently launched CPU utilization by app profile metric includes method and table dimensions. These additional dimensions provide more granular observability into the Bigtable cluster’s CPU usage and how your Bigtable instance resources are being used. These observability metrics tell you what applications are accessing what tables with what API method, making it much easier to quickly troubleshoot and resolve issues.Learn moreTo get started with Bigtable, create an instanceor try it out with a Bigtable Qwiklab.Check out Youtube videos for step by step introduction to how Bigtable can be used in real world applications like Personalisation and Fraud detection.Learn how you can migrate data from HBase to Bigtable
Quelle: Google Cloud Platform
