In a previous blog post we took a look at the Red Hat Container Development Kit (CDK) and how it can be used to build and deploy applications within a development environment that closely mimics a production OpenShift cluster. In this post, we’ll take an in-depth look at what a production OpenShift cluster looks like — the individual components, their functions, and how they relate to each other. We’ll also check out how OpenShift supports scaling up and scaling out applications in a production environment.
Virtualization technologies have evolved such that support for multiple networks on a single host is a must-have feature. For example, Red Hat Enterprise Virtualization allows administrators to configure multiple NICs using bonding for several networks to allow high throughput or high availability. In this configuration, different networks can be used for connecting virtual machines (using layer 2 Linux bridges) or for other uses such as host storage access (iSCSI, NFS), migration, display (SPICE, VNC), or for virtual machine management. While it is possible to consolidate all of these networks into a single network, separating them into multiple networks enables simplified management, improved security, and an easier way to track errors and/or downtime.
The aforementioned configuration works great but leaves us with a network bottleneck at the host level. All networks compete on the same queue in the NIC / in a bonded configuration and Linux will only enforce a trivial quality of service queuing algorithm, namely: pfifo_fast, which queues side by side, where packets can be enqueued based on their Type of Service bits or assigned priority. One can easily imagine a case where a single network is hogging the outgoing link (e.g. during a migration storm where many virtual machines are being migrated out from the host simultaneously or when there is an attacker VM). The consequences of such cases can include things like lost connectivity to the management engine or lost storage for the host.
No, last night’s news wasn’t an early April Fool’s Day joke: Red Hat Enterprise Linux is now available through a no-cost developer subscription as part of the Red Hat Developers Program. All that’s needed is an email address to register for the program and developers then have access to not only Red Hat Enterprise Linux (as part of the Red Hat Enterprise Linux Developer Suite) but also the entire Red Hat JBoss Middleware portfolio and the Red Hat Container Development Kit (CDK).
Yesterday, Intel launched the Xeon E5-2600 v4 processor family with 26 new world records on industry-standard benchmarks. Once again, Intel’s innovation, driven by Moore’s law, has enabled faster computing for the enterprise world.
Red Hat and Intel have enjoyed a long history of collaboration across a full spectrum of enterprise IT – covering a wide range of use cases, from applications running on physical servers to virtualized and cloud-based deployments. It should come as no surprise that many of
Some time ago, two different projects were started in the open source community, namely: Ipsilon and Keycloak. These projects were started by groups with different backgrounds and different perspectives. In the beginning, it seemed like these two projects would have very little in common… though both aimed to include
Identity management solutions integrate systems, services, and applications into a single ecosystem that provides authentication, access control, enterprise SSO, identity information and the policies related to those identities. While I have dedicated time to explaining how to provide these capabilities to Linux systems – it is now time to broaden the scope and talk a little bit about services and applications.
IT decision makers seem to be up in arms regarding discussions on “next generation” technologies. In the past three months it has been nearly impossible to hold a conversation where the terms cloud, OpenStack, or (Linux) containers don’t surface. Hot topics and buzzwords aside, it has become clear (to me) that the right mix of market conditions are causing organizations to express a renewed interest in enterprise virtualization.
Many organizations are now ready to adopt the next generation of server hardware. The popular Ivy Bridge and Sandy Bridge chipsets from Intel are four to five years old and those who purchased such hardware tend to refresh their equipment every four to five years. In addition, we see Intel Haswell technology approaching its third anniversary. Organizations that lease hardware on a three year cycle will also be looking at what the next generation of hardware has to offer.
There is a lot of confusion around which pieces of your application you should break into multiple containers and why. I recently responded to this thread on the Docker user mailing list which led me to writing today’s post. In this post I plan to examine an imaginary Java application that historically ran on a single Tomcat server and to explain why I would break it apart into separate containers. In an attempt to make things interesting – I will also aim to
Red Hat has long advocated for the importance of cross-industry IT standards, with the intention of enabling ecosystems with broad industry participation and providing a common basis for innovation. Perhaps even more importantly, these standards can help drive adoption of new technologies within enterprises, pushing the cycle of innovation even further along.
With ARM being one of these emerging ecosystems, we wanted to provide a snapshot of a recent event that highlights some of the standards-based work happening in this growing community: last week’s Linaro Connect conference in Bangkok, Thailand.
In last year’s blog series, I covered both direct and indirect Active Directory integration options. But I never explained what we actually suggest / recommend. Some customers looking at indirect integration saw only the overhead of providing an interim server and the costs related to managing it. To be clear, these costs are real and the overhead does exist. But we still recommend