glossary_letter: H

<< Back to Technical Glossary

HTTP Compression Definition

HTTP compression can increase website performance. Size reduction of up to 70 percent depending on the document reduces bandwidth capacity needs. Over time, servers and clients support new algorithms and existing algorithms become more efficient.

Practically speaking, both servers and browsers have HTTP data compression methods implemented already, so web developers need not implement them specifically beyond a need to enable HTTP compression web configuration standards.

There are three different levels of HTTP compression:

• Specific optimized methods compress some file formats;
• The system encrypts and transmits the resource compressed from end to end at the HTTP level;
• The system can define compression between two nodes at the HTTP connection level.

File format compression

Each type of data has some inherent wasted space or redundancy. Typical redundancy rates for text hovers at as much as 60 percent, with much higher rates for video, audio, and other media types. Unlike with text, the need to regain space and optimize storage became apparent very early on with these various kinds of media that use extensive amounts of storage space for data. For this very reason, engineers designed the optimized compression algorithm that file formats use.

There are two basic kinds of compression algorithms for files, lossless and lossy:

• The lossless compression-uncompression cycle matches with the original byte to byte and doesn’t alter recovered data. PNG and GIF images use lossless compression.
• The lossy compression cycle alters the original data for the user in a way that is ideally imperceptible. The JPEG and video formats online are lossy.
• Some formats, like WebP, can be used for both lossless and lossy compression. Lossy algorithms can typically be configured for higher or lower quality as they compress more or less. For ideal site performance, balance maximum compression with desired quality levels.

Lossy compression algorithms tend to be more efficient than lossless algorithms.

End-to-end compression

End-to-end compression yields the largest performance improvements for sites and describes server compression of the body of a message that lasts unchanged until the message reaches the client. Intermediate nodes of all kinds leave the message body unaltered. All modern servers and browsers support end-to-end compression so the only issue is which compression algorithm optimized for text the organization wants to use.

Hop-by-hop compression

Though similar to end-to-end compression, hop-by-hop compression differs in one fundamental way: the compression takes place between any two nodes on the path between the client and the server on the body of the message, not on the resource in the server, so it doesn’t result in a specific, transmissible representation in the same way. Successive connections between intermediate nodes might apply different compressions. In practice, hop-by-hop compression is rarely used, in part because it is transparent for both client and server.

FAQs

What is HTTP Compression?

It is possible to improve the web performance of any network-based application by reducing the server to client data transfer time. There are two ways to improve page load times: 

• Reducing how often the server has to use the cache control and send data; 
• Using HTTP compression to reduce the size of transferred data.

Just like it sounds, before a file is transmitted to a client, HTTP compression squeezes its size on the server, reducing page load times and making file transfers faster. There are two major categories of compression: lossless and lossy.

Lossy compression creates a data surrogate, so reversing the process with lossy decompression does not permit retrieval of the original data. Depending on the compression algorithm quality, the surrogate resembles the original more or less closely. In browsers, this technique is primarily used with the JPEG image, MPEG video, and MP3 audio file formats which are all more forgiving of dropped details in terms of what humans perceive. The resulting data size savings is significant.

In contrast, lossless decompression results in an identical, byte-for-byte copy of the original data. Many web file formats throughout the web platform use lossless compression, internally and in the HTTP layer for texts. Some relevant file formats for lossless compression include GIF, PDF, PNG, SWF, and WOFF.

To improve web performance, activate compression for all files except those that are already compressed. Attempting to activate HTTP compression for already compressed files like GIF or ZIP can be unproductive, wasting server time, and can even increase the size of the response message.

Both client and server must communicate over the support and usage of any compression format(s) to properly decompress files. The most commonly used HTTP body compression formats are Brotli (br), Gzip, and DEFLATE, but we will discuss more formats and algorithms below.

The client clarifies which content encoding it can understand in the Accept-Encoding header or Accept-Encoding request HTTP compression header. The server responds with the Content-Encoding response HTTP header, which indicates which compression algorithm was used.

Those steps covered content compression for files in the body of an HTML file, but did not address the actual HTTP header. Yet reducing the size of the HTTP header can greatly impact performance, since it is sent with every response.

To sum up, you can improve performance by systematically compressing uncompressed content like text. You can follow up by using HTTP/2 and its tool for secure HTTP header compression where possible. Finally, to guarantee optimal user experience and optimize digital services delivery, monitor how web servers, CDNs, and other third party service providers deliver content.

Tips and Best HTTP Compression Practices

Here are some tips and best practices surrounding HTTP compression.

Content Encoding Gzip vs DEFLATE

It is easy to discuss HTTP compression as if it is a monolithic feature, but actually, HTTP defines how a web client and server can agree to use a compression scheme in the Accept-Encoding headers and Content-Encoding headers to transmit content. The most commonly used HTTP body compression formats are Brotli (br), Gzip, and DEFLATE, with DEFLATE and Gzip mostly dominating the scene.

The patent-free DEFLATE algorithm for lossless data compression combines Huffman encoding and the LZ77 algorithm and is specified in RFC 1951. DEFLATE is easy to implement and compresses many data types effectively.

There are numerous open source implementations of DEFLATE, with zlib being the standard implementation library most people use. Zlib provides:

• data compression and decompression functions using DEFLATE/INFLATE
• the zlib data format which wraps DEFLATE compressed data with a checksum and header

Another compression library that uses DEFLATE to compress data is Gzip. More accurately, most Gzip compression implementations use the zlib library internally to DEFLATE or INFLATE. This results in a unique Gzip data format, also named Gzip, which wraps DEFLATE compressed data with a checksum and header.

Due to early problems with DEFLATE, some users prefer to only use Gzip.

HPACK

Typically, HTTP headers are not compressed, as HTTP content-encoding based compression applies to the response body only. This leaves a significant weakness in a HTTP compression plan. Along these lines, it is unusual for content-encoding to affect request bodies.

HTTP 2 header compression was introduced with the HTTP/2 protocol in the form of HPACK. HPACK was designed to resist attacks preying on the SPDY protocol such as the CRIME exploit, but it is limited in that it only works efficiently where the header doesn’t change from message to message. Before HPACK, attempts at header compression used Gzip, but this kind of implementation introduced security breaches that made it vulnerable to attacks. HTTP/2 draft 14 enables HPACK, but it’s often best to use content-encoding since draft 12 removed per-frame Gzip compression for data.

Compressing Request Bodies

Although HTTP allows clients to use the same content-encoding mechanism to compress request bodies they use for HTTP responses, in practice, this feature is mostly unused by browsers and used only rarely by other types of HTTP clients. There are a few reasons for this.

Most importantly, a client has no way of knowing whether a server accepts compressed requests, and many do not. In contrast, a server can examine the accept-encoding request header to determine whether a client accepts the compressed version of responses.

As a result, HTML forms do not yet allow authors to specify to compress request bodies.

Modern web applications can use script in browser APIs as a workaround:

1. Load a file using HTML5 File API for upload into JavaScript
2. Use a script-based compression engine to compress the file
3. Upload the compressed file to the server

Compression Bombs

Servers may be wary of supporting compressed uploads due to “compression bombs.” This just refers to the peak compression ratio of the DEFLATE algorithm which approaches 1032 to 1. This means a one megabyte upload can rapidly become a 1 gigabyte explosion for a server. These attacks are most potent against servers, which require a single CPU to simultaneously serve thousands of users, compared to client applications like browsers.

Just like any other malicious activity, protecting against these kinds of crafted compression streams demands careful planning and additional diligence during implementation.

Best Practice: Minify, then Compress

Minification is the removal of all unnecessary characters from the source code without changing its functionality. Minifying your scripts before compression is a critical first step, because after decompression, the files still use whatever original memory they require. This also applies to image file types. Minification saves memory on the client, on memory-constrained mobile devices, and the system.

Challenges and Benefits of HTTP Compression

HTTP compression is a relatively simple feature of HTTP, yet there are several challenges to address to ensure its proper use:

1. Compressing only compressible content
2. Selecting the correct compression scheme for your visitors
3. Properly configuring the web server to send compressed content to capable clients
4. Maintaining HTTP compression security

Compressing Only Compressible Content

Enable HTTP response compression only for content that is not already natively compressed. This is not limited to text resources, such as CSS, HTML, and JavaScript, although because they are not natively compressed file formats, they certainly should be compressed. But a focus solely on these 3 types of files is short-sighted.

Other common web text resource types that should be subject to HTTP compression include:

• HTML CSS components (HTC files). HTC files are a proprietary feature of Internet Explorer which bundle code, markup, and style information for CSS behaviors and are used in fixes or to support added functionality.
• ICO files. ICO files are often used as favicons, but like BMP images, they are not natively compressed.
• JSON. A subset of JavaScript, JSON is used for API calls as a data format wrapper.
• News feeds. Both Atom and RSS feeds are XML documents (see below).
• Plain Text. All plain text files should be compressed, and they come in many forms, such as LICENSE, Markdown, and README files.
• Robots.txt. Robots.txt represents a major opportunity to enable compression HTTP because it can consume massive bandwidth unbeknownst to human users and become very large as it is repeatedly accessed by search engine crawlers. This specific text file tells search engines where to crawl on web sites. Since Robots.txt does not appear in JavaScript-based web analytics logs and is not usually accessed by humans, it is often forgotten.
• SVG images. Serve SVG files with HTTP compression. SVG images are just XML documents, but they are not natively compressed, and because they have a different file extension and MIME type, it’s easy to remember to compress XML documents, and forget SVG images. It’s also easy to unwittingly have SVG images on a website.
• XML. XML is structured text used for API calls as a data format wrapper or in standalone files such as Google’s sitemap.xml or Flash’s crossdomain.xml.

Avoid using HTTP compression on natively compressed content for two reasons. First, there is a cost of using HTTP data compression schemes. If there is no achievable compression to be had, it’s wasted CPU effort.

Worse, applying HTTP compression to something that’s natively compressed won’t make it smaller—and might do just the opposite by adding compression dictionaries, headers, and checksums to the response body. More comprehensive platforms can monitor in real time to check HTTP compression performance alert users for wasted CPU time during HTTP compression, or the problem of making files larger, and some include specific HTTP compression test capabilities. Both issues can typically be fixed by fixing a problem with HTTP compression web configuration.

Next, review how your web server is configured to compress content. Most browsers allow users to specify either a list of MIME types or a list of file extensions to compress, or both. Review this list and carefully configure the server carefully based on what you find. Ensure that an error such as a missing MIME type declaration or file extension won’t allow uncompressed content to leak through.

To sum up:

• Be sure to serve all non-natively compressed content using HTTP compression
• Never waste CPU cycles, load time, and bandwidth compressing already compressed content
• Ensure compatibility by sticking to Gzip
• Verify that HTTP compression settings match application content and structure reflected in code and server configuration
• Validate that the configuration works using tools

Does The VMware NSX Advanced Load Balancer Offer HTTP Compression?

Yes. The VMware NSX Advanced Load Balancer offers two options for HTTP compression: normal compression and aggressive compression.

VMware NSX Advanced Load Balancer’s normal compression option uses Gzip level 1, and consumes fewer CPU cycles as it compresses 75% of the text HTML content. The VMware NSX Advanced Load Balancer’s aggressive compression option uses Gzip level 6 and compresses 80% of the text content.

The VMware NSX Advanced Load Balancer also offers two compression modes. In auto mode, VMware NSX Advanced Load Balancer selects the optimal setting for compression, dynamically tuning the settings based on available SE’s CPU resources and clients.

Custom mode gives users more granular control over who should receive what level of compression, and enables the creation of custom filters with different levels of compression for different clients. For example, create filters for slower mobile clients with aggressive compression levels ensuring compression is disabled for faster clients on the local intranet.

Learn more about HTTP compression and VMware NSX Advanced Load Balancer here.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

Hardware Security Module Definition

A hardware security module (HSM) is a dedicated cryptographic processor that manages and safeguards digital keys. Designed specifically to protect the crypto key lifecycle, hardware security modules perform encryption and decryption functions for strong authentication, digital signatures, and other cryptographic functions.

HSMs serve as trust anchors to create hardened, tamper-resistant environments for storing cryptographic keys. Traditionally, a hardware security module includes one or more secure cryptoprocessor chips and usually exists as an external device or plug-in card that attaches directly to a network server or computer.

FAQs

What is a Hardware Security Module?

A general purpose hardware security module is a standards-compliant cryptographic device that uses physical security measures, logical security controls, and strong encryption to protect sensitive data in transit, in use, and at rest. An HSM might also be called a secure application module (SAM), a personal computer security module (PCSM), or a hardware cryptographic module.

The hardware security module creates a trusted environment for performing a variety of cryptographic operations, including key exchange, key management, and encryption. In this context, “trusted” means free of malware and viruses, and protected from exploits and unauthorized access.

An HSM can be trusted because:

• It is built atop certified, well-tested, specialized hardware.
• It runs a security-focused OS.
• Its entire design actively protects and hides cryptographic information.
• It has limited access to the network through a moderated interface that is strictly controlled by internal rules.

Without a hardware security module, ordinary operations and cryptographic operations take place in the same locations, so attackers can access ordinary business logic data alongside sensitive information such as keys and certificates. Hackers can install arbitrary certificates, expand unauthorized access, alter code, and otherwise dangerously impact cryptographic operations.

How Do Hardware Security Modules Work?

Encryption, the process of rendering sensitive data indecipherable except to those with authorized access, forms the basis for an HSM’s core functionality. Secure decryption and message authentication are also part of HSM functionality.

Randomly generated values are essential to the encryption process, because they are used to create encryption keys. Decrypting that sensitive information is always just one step away with the keys in hand, so storage of encryption keys in a secure environment is essential.

Hardware security modules generate and store encryption keys used among various devices. They have special hardware to create entropy and generate high quality random keys. Larger organizations may operate multiple HSMs concurrently instead of just one. Whether one or many HSMs are deployed, a streamlined, centralized key management system based on both external regulations and strong internal security policies improves security and compliance.

HSMs are typically certified to internationally recognized standards such as FIPS 140 or Common Criteria. This is related to the critical function of HSMs in securing infrastructure and applications, and the related need to ensure users that product and cryptographic algorithm design and implementation are sound. The highest achievable certification level of FIPS 140 security is Security Level 4. Users often validate the security of an HSM against the Payment Card Industry Security Standards Council’s defined requirements for HSMs in financial payments applications.

Hardware Security Module Architecture

HSMs may have tamper-proof or tamper-resistant features. For example, hardware security modules may show visible signs of logging and alerting, or may become inoperable if they are tampered with. Some HSMs may delete keys upon detection of tampering. Hardware security modules are typically protected by tamper resistant, tamper evident, or tamper responsive packaging, and contain one or multiple cryptoprocessor chips or a module containing a combination of chips to prevent bus probing and tampering.

HSMs can generally be clustered for high availability since they are often part of mission-critical infrastructure such as an online banking application or a public key infrastructure. Some hardware security modules enable business continuity and conform to the high-availability requirements of data center environments. For example, they may feature field replaceable components or dual power supplies to ensure availability in spite of disaster.

Some HSMs can internally execute specially developed modules in native C language, Java, .NET, or other programming languages. Such a capability can assist an organization that needs to execute business logic or special algorithms in a trusted environment. Next-generation hardware security modules can often tackle running and loading COTS software and operating systems and other complex tasks without demanding complete reprogramming and customization.

Hardware Security Module Applications

Any application that employs digital keys may use a hardware security module. Generally, to justify the use of an HSM, compromise of the keys would need to cause serious, negative impact. In other words, digital keys must be of high value to be generated and maintained in a hardware security module USB or other device.

The key functions of an HSM are as follows:

• For a certificate authority, the HSM is an onboard cryptographic key generation and secure key storage facility, particularly for primary keys, or the most sensitive, top level keys.
• Assists in the authentication process by verifying digital signatures.
• Verifies integrity of sensitive data stored in relatively less secure locations such as databases and encrypts the sensitive data securely for storage.
• Generates secure keys for smart card production.
• Manages keys for storage devices such as tape or disk and transparent data encryption keys for databases.
• Provides both physical and logical protection of sensitive information, including cryptographic keys, from non-authorized use, disclosure, and potential attackers.
• Supports both asymmetric or public-key cryptography and symmetric cryptography.
• Some HSM systems act as hardware cryptographic accelerators for SSL connections and many offer asymmetric key operations significant CPU offload. Most HSMs also now support elliptic curve cryptography (ECC), which provides stronger encryption despite shorter key lengths.
• For applications that are performance-critical and must use HTTPS (SSL/TLS), an SSL acceleration HSM can relocate RSA operations from the host CPU to the HSM device. RSA operations usually demand several large integer multiplications, and typical hardware security modules can perform about 1 to 10,000 1024-bit RSA operations/second. Certain specialized hardware based security modules can achieve 20,000 operations per second.
• In PKI environments, registration authorities (RAs) and certification authorities (CAs) may use HSMs to generate, manage, and store asymmetric key pairs.
• Bank hardware security modules or card payment system hardware security modules are specialized HSMs applied in the payment card industry. As such, these HSMs support both typical hardware security module functions and specialized functions that transaction processing and industry standards for compliance demand. Typical applications are personalization of payment cards and authorization of transactions. The major standard-setting organizations for banking HSMs are ANS X9, the Payment Card Industry Security Standards Council (PCISSC), and ISO.
• Some registries store core material for signing large zone files in HSMs. For example, OpenDNSSEC is an open source hardware security module tool for managing signing of DNS zone files.
• HSMs can be used as cryptocurrency wallets.

HSMs vs Trusted Execution Environments (TEEs) and Trusted Platform Modules (TPMs)

A trusted execution environment (TEE) is a secure area created as part of a main computer processor. It is designed to ensure that data and code inside the TEE is protected in terms of integrity and confidentiality.

A trusted platform module (TPM) is a special chip designed and soldered into the motherboard so that accessing its secret keys is both difficult and immediately obvious. This physical step is intended to provide a hardware source of trust in the computing system. TPMs do not generally add computational capacity although they can offer some basic capabilities such as random keys generation, or the encryption of small amounts of data.

A hardware security module, in contrast, keeps the encryption keys external to the operating system. Although there is some overlap between TEEs, TPMs, and HSMs, they are not the same and do not provide identical benefits. Like TPMs, HSMs also make physical tampering obvious, but they tend to provide higher levels of protection than both TPMs and TEEs.

Some argue that HSMs need not depend on physical tamper protection and proprietary hardware architectures any longer. Instead, they can exploit the security properties of TEEs to create a “soft HSM” or virtual hardware security module. For example, Google’s Cloud HSM is billed as a cloud hardware security module, a totally virtual service version of the HSM.

These solutions certainly simplify scaling using cloud-native technologies. However, an even greater level of security can be achieved by implementing an HSM using those same cloud-native technologies to improve performance and reduce operational challenges related to hardware.

To summarize:

• TEEs offer a general, built-in processing environment. They are part of a chipset.
• TPMs provide limited processing capacities, measurement of the boot sequence and other components, and a physical source for trust. They are an inexpensive built-in component.
• HSMs are the highest security environment for sensitive data processing, management or storage of secret keys, and cryptographic operations. They are typically more costly, external devices, although cloud technologies can help render them less expensive and more scalable.

Benefits and Features of Hardware Security Modules

The main benefits of hardware security modules are: physical access protection, secure management of key material, secure generation of keys, and secure execution environment.

There is no way to completely protect conventional IT systems from external attack. In contrast, HSMs boast a range of protective mechanisms designed to deter external attack and any physical tampering. These typically include: voltage and temperature sensors, resin-embedded chips, and drill protection foil.

For example, if an attacker attempts to drill open an HSM device, either by breaking open the casing or using acid or icing up the casing to erode the layers, sensors immediately register the attack, trigger an alarm, and initiate any specified countermeasures set forth in the configuration, such as the deletion of keys.

Keys are only useful when they are random and well-protected, or they are easily guessed by attackers. In conventional IT systems, limited means exist for generating secure keys, because they are relying on traditional commands which process if-then situations. Unfortunately, knowing the “if” or input data for any given command can allow a skilled attacker to predict the “then” or output data.

HSMs defeat this issue by generating truly random keys. They do this by registering data from random physical processes in the vicinity such as atmospheric noise or atomic decay processes to produce unpredictable values to use as the basis for random keys.

Importantly, a hardware security module generates, stores, and uses these keys in executing signatures, encryptions, and other cryptographic operations—and all of these security-critical processes take place inside the secure environment of the HSM.

Since the keys for cryptographic operations never escape the HSM, the environment provides maximum protection against logical attack: it is virtually impossible to steal them. Some hardware security modules also protect users from Trojans and insider attacks by providing a secure execution environment for user applications. In these systems, the entire application is programmed and executed inside the secure space of the HSM.

Best Practices of Using HSMs

The following are the most important benefits and features of hardware security modules to consider:

FIPS 140-1 or 140-2 compliance and validation. The Federal Information Processing Standard (FIPS) defines four levels for validating HSMs. Validation means an HSM has passed a reasonable baseline of security tests performed at FIPS accredited testing facilities by qualified professionals. This goes far beyond mere compliance with FIPS 140.

Proprietary versus open algorithms. Avoid secret proprietary algorithms unless they are in addition to options that are open and widely accepted yet secure. (If your HSM uses both, ensure it is configured properly so it will not use the proprietary algorithms.) Look for DSA or RSA based cryptographic algorithms for digital signatures. For hashing, MD5 or SHA-1 are good alternatives. 3-DES is a good choice for encryption.

Strong random number generation. Any HSM must be capable of strong random number generation (RNG) or pseudo-random number generation in order to support key generation and other cryptographic functions.

Scalability. Hardware security module architecture should support load balancing and clustering so it can scale with growing network architecture.

A secure time source. Secure non-repudiation and auditing demand a secure time and date source for logged messages. An easily hacked server-based time source is among the few common hardware security module vulnerabilities. Only an authenticated administrator should be permitted to change the time on an HSM which should also securely log the event.

Ease of use. A standardized developer interface and secure, simple user interface both facilitate use of the HSM and help avoid expensive errors.

Well-documented device installation. Clearly document all installation and maintenance events, including battery replacements, known hardware conflicts, machine compatibility issues, and physical switches on the device.

Key backup. Secure key backup is critical for any HSM used for verifying or encrypting data in a database, or within a certificate authority. Optimally, backup keys to multiple smart cards, and store them separately.

Key protection. A hardware security module should protect keys by encrypting any that are exported beyond its physical boundary.

Tamper-resistance. The HSM should delete all sensitive data or “zeroize” itself should it detect any anomalous electrical activity, physical penetration, unusual temperature, or other signs of tampering. This stops a successful attacker from retrieving the secret keys once they have gained physical access.

Of course, there are several disadvantages of hardware security modules—mostly surrounding cost, depending on the levels of security and functionality that the facts demand. Some HSMs are also difficult to implement and upgrade. However, harnessing cloud-native technologies and their inherent scalability can help with each of these issues.

Does The VMware NSX Advanced Load Balancer Offer Hardware Security Module Solutions?

The right hardware security module ensures your business addresses compliance requirements with solutions for blockchain, bulk key generation, certificate signing, code or document signing, data encryption, digital signatures, DNSSEC, GDPR, hardware key storage, paper-to-digital initiatives, IoT, PCI DSS, transactional acceleration, and more.

The VMware NSX Advanced Load Balancer supports integration of networked hardware security module (HSM) products, including Thales nShield and SafeNet Network HSM. Learn more about integrating HSMs with VMware NSX Advanced Load Balancer here.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

Hybrid Cloud Definition

Hybrid-cloud A hybrid cloud architecture is mix of on-premises, private, and public cloud services with orchestration between the cloud platforms. Hybrid cloud management involves unique entities that are managed as one across all environments.

FAQs

What is Public vs. Private vs. Hybrid Cloud?

Innovations in the cloud have resulted in a move from single-user private clouds to multi-tenant public clouds and hybrid clouds. This evolution in cloud infrastructure has seen an increase in the use of hybrid cloud solutions. The cloud types have the following differences:

• Private Cloud: Serves a single-user. It can be self-hosted or hosted by a cloud provider.

• Public Cloud: These represent infrastructure-as-a-service offerings purchased from Amazon, Google, IBM or Microsoft.

• Hybrid Cloud: Hybrid cloud architecture combines two different types of infrastructure into a single heterogeneous environment. It can be any combination of a traditional data center, private cloud, and public cloud. Even though these environments remain different, they can work together effectively and function as one environment.

What are Some Hybrid Cloud Examples?

Hybrid cloud architecture works well for the following industries:

• Finance: Financial firms are able to significantly reduce their space requirements in a hybrid cloud architecture when trade orders are placed on a private cloud and trade analytics live on a public cloud.

• Healthcare: When hospitals send patient data to insurance providers, hybrid cloud computing ensures HIPAA compliance.

• Legal: Hybrid cloud security allows encrypted data to live off-site in a public cloud while connected o a law firm’s private cloud. This protects original documents from threat of theft or loss by natural disaster.

• Retail: Hybrid cloud computing helps companies process resource-intensive sales data and analytics.

What is Hybrid Cloud Strategy?

Tech professionals use hybrid cloud strategy in the following ways, according to a 451 Research report:

• Dynamically move workloads to the most appropriate IT environment based on cost, performance and security.

• Utilize on-premises resources for existing workloads, and use public or hosted clouds for new workloads.

• Run internal business systems and data on premises while customer-facing systems run on infrastructure as a service (iaaS), public or hosted clouds.

Increasingly, a hybrid cloud model is called a hybrid cloud environment. This environment strategy involves running applications in different environments with multiple public and private cloud vendors, while each element lives in one hybrid domain.

Why use Hybrid Cloud?

Hybrid cloud architecture allows an enterprise to move data and applications between private and public environments based on business and compliance requirements.

For example, customer data can live in a private environment. But heavy processing can be sent to the public cloud without ever having customer data leave the private environment. Hybrid cloud computing allows instant transfer of information between environments, allowing enterprises to experience the benefits of both environments.

Hybrid cloud benefits include the following management tools:

• Choice: The additional choice of multiple environments provides flexibility and the ability
to avoid vendor lock-in.

• Disaster Avoidance: Multiple environments ensures compute resources are always available to avoid downtime due to natural disaster or human error.

• Compliance: Many hybrid cloud environments can help enterprises achieve their goals for governance, risk management and compliance regulations.

How does The VMware NSX Advanced Load Balancer Help with Hybrid Cloud Deployments?

With enterprises running their applications in a mix of private data centers and multiple public cloud environments, choices for application services are increasingly driven by technologies that can be infrastructure agnostic and those that have uniform architecture and user experience irrespective of the environment.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

For more information on hybrid cloud deployments see the following resource:

<< Back to Technical Glossary

Hardware Load Balancer Definition

A hardware load balancer, also known as a hardware load balancing device (HLD), is a proprietary appliance built on custom ASICs to distribute traffic across multiple application servers on the network.

FAQs

What is a Hardware Load Balancer?

A hardware load balancer is a hardware device with a specialized operating system that distributes web application traffic across a cluster of application servers. To ensure optimal performance, the hardware load balancer distributes traffic according to customized rules so that application servers are not overwhelmed.

Traditionally, hardware load balancers and application servers are deployed in on-premises data centers and the number of load balancers depends on the expected amount of peak traffic. Load balancers are usually deployed in pairs in case one fails.

How does a Hardware Load Balancer Work?

A hardware load balancer sits between incoming traffic and internal servers, essentially acting as a “traffic cop.” When clients visit the website, they are sent first to the load balancer, which then directs clients to different servers. Most enterprises also deploy load balancers and servers in multiple locations, a procedure known as global server load balancing (GSLB). GSLB not only provides optimized response times, but also ensures high availability in disaster recovery situations. If one data center fails, GSLB systems can redirect network traffic to other available sites, minimizing the impact on end-users.

Hardware Load Balancers vs. Software Load Balancers?

The most obvious difference between hardware vs. software load balancers is that hardware load balancers require proprietary, rack-and-stack hardware appliances, while software load balancers are simply installed on standard x86 servers or virtual machines. Network load balancer hardware is typically over provisioned — in other words, they are sized to be able to handle occasional peak traffic loads. In addition, each hardware device must be paired with an additional device for high availability in case the other load balancer fails.

Another critical difference between hardware and software load balancers lies in the ability to scale. As network traffic grows, data centers must provision enough load balancers to meet peak demand. For many enterprises, this means that most load balancers stay idle until peak traffic times (e.g. Black Friday).

If traffic volumes unexpectedly exceed capacity, end-user experiences are significantly impacted. On the other hand, software load balancers are able to scale elastically to meet demand. Whether network traffic is low or high, software load balancers can simply autoscale in real time, eliminating over-provisioning costs and worries about unexpected traffic surges.

In addition, hardware load balancer configuration can be complex. Software load balancers architected on software-defined principles cross multiple data centers and hybrid-/multi-cloud environments. In fact, hardware appliances are not compatible with cloud environments, whereas software load balancers are compatible with bare metal, virtual, containers, and cloud platforms.

Where does a Hardware Load Balancer Fall short?

When choosing load balancers, enterprises should keep hardware load balancer costs in mind. All hardware appliances come with standard over-provisioning requirements and the need for additional manpower to configure and maintain the devices. Moreover, enterprises that use hardware load balancers cannot take advantage of cloud computing, which lowers CapEx and OpEx costs while offering higher performance, automation, and elasticity. Overall, even the best hardware load balancer will greatly increase enterprise TCO (especially when deploying global server load balancing).

Does The VMware NSX Advanced Load Balancer Offer a Hardware Load Balancer?

No, the VMware NSX Advanced Load Balancer does not offer a hardware load balancer. However, for customers who prefer the appliance form factor, VMware NSX Advanced Load Balancer can be deployed in bare metal servers or on NFV appliances like Cisco CSP 2100 delivering the convenience of a familiar deployment model with benefits of a software-defined architecture. The VMware NSX Advanced Load Balancer is an intent-based L4-L7 application services platform that is deployed on bare metal servers, virtual machines, containers, public clouds, and multi-cloud environments. Instead of forcing enterprises to over provision load balancers, VMware NSX Advanced Load Balancer offers on-demand, elastic autoscaling that matches real-time traffic. Unlike most hardware load balancers that essentially act as black boxes, VMware NSX Advanced Load Balancer also delivers unparalleled end-to-end visibility, reducing troubleshooting time to minutes.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos or watch the Global Server Load Balancing How To Video here:

For more information on hardware load balancers see the following resources:

<< Back to Technical Glossary

High Availability Definition

High Availability (HA) describes systems that are dependable enough to operate continuously without failing. They are well-tested and sometimes equipped with redundant components.

“Availability” includes two periods of time: how much time a service is accessible, and how much time the system needs to respond to user requests. High availability refers to those systems that offer a high level of operational performance and quality over a relevant time period.

FAQs

What is High Availability?

When it comes to measuring availability, several factors are salient. These include recovery time, and both scheduled and unscheduled maintenance periods.

Typically, availability as a whole is expressed as a percentage of uptime defined by service level agreements (SLAs). A score of 100 percent characterizes a system that never fails.

What Are High Availability Clusters?

High-availability clusters are computers that support critical applications. Specifically, these clusters reliably work together to minimize system downtime.

In terms of failover cluster vs high availability preference, a failover cluster, which is a redundant system triggered when the main system encounters performance issues, is really just a strategy to achieve high availability.

Why is High Availability Important?

To reduce interruptions and downtime, it is essential to be ready for unexpected events that can bring down servers. At times, emergencies will bring down even the most robust, reliable software and systems. Highly available systems minimize the impact of these events, and can often recover automatically from component or even server failures.

High Availability Architecture

Of course, it is critical for systems to be able to handle increased loads and high levels of traffic. But identifying possible failure points and reducing downtime is equally important. This is where a highly available load balancer comes in, for example; it is a scalable infrastructure design that scales as traffic demands increase. Typically this requires a software architecture, which overcomes hardware constraints..

In this process, users set up servers to switch responsibilities to a remote server as needed. They should also evaluate each piece of hardware for durability using vendor metrics such as mean time between failures (MTBF).

How High Availability Works

To achieve high availability, first identify and eliminate single points of failure in the operating system’s infrastructure. Any point that would trigger a mission critical service interruption if it was unavailable qualifies here.

There may be singular components in your infrastructure that are not single points of failure. One important question is whether you have mechanisms in place to detect any data loss or other system failures and adapt quickly. Another is whether you have redundant system components in place that can cover the same tasks.

Which High Availability Products Do You Need?

In practice, high availability products are the first line of defense, although it takes more to achieve this level of durable performance. Important factors include: data quality, environmental conditions, hardware resilience, and strategically durable networks and software.

There are many ways to lose data, or to find it corrupted or inconsistent. Any system that is highly available protects data quality across the board, including during failure events of all kinds.

Highly available hardware includes servers and components such as network interfaces and hard disks that resist and recover well from hardware failures and power outages.

Another part of an HA system is a high availability firewall. These are typically multiple web application firewalls placed strategically throughout networks and systems to help eliminate any single point of failure and enable ongoing failover processing.

Networks and software stacks also need to be designed to resist and recover from failures—because they will happen, even in the best of circumstances.

What is the Difference Between High Availability and Redundancy?

Redundancy alone cannot ensure high availability. A system also needs failure detectability mechanisms.

The ability to conduct high availability testing and the capacity to take corrective action each time one of the stack’s components becomes unavailable are also essential.

Top-to-bottom or distributed approaches to high availability can both succeed, and hardware or software based techniques to reduce downtime are also effective.

Redundancy is a hardware based approach. On the other hand, implementing high availability strategies nearly always involves software.

High Availability vs Fault Tolerance

High availability and fault tolerance both refer to techniques for delivering high levels of uptime. However, fault tolerant vs high availability strategies achieve that goal differently.

Fault tolerant computing demands complete redundancy in hardware. Multiple systems operate in tandem to achieve fault tolerance, identically mirroring applications and executing instructions together. When the main system fails, another system should take over with no loss in uptime.

To achieve fault tolerant computing, you need specialized hardware. It must be able to immediately detect faults in components and enable the multiple systems to run in tandem.

This kind of system retains the memory and data of its programs, which is a major benefit. However, it may take longer to adapt to failures for networks and systems that are more complex. In addition, software problems that cause systems to crash can sometimes cause redundant systems operating in tandem to fail similarly, causing a system-wide crash.

In contrast, a high availability solution takes a software- rather than a hardware-based, approach to reducing server downtime. Instead of using physical hardware to achieve total redundancy, a high availability cluster locates a set of servers together.

These high availability servers both possess failover capabilities and monitor each other. If the primary server has issues, only one of the backup servers needs to detect them. It can then restart the problem application that tripped up the crashed server.

High availability systems recover speedily, but they also open up risk in the time it takes for the system to reboot. Fault tolerant systems protect your business against failing equipment, but they are very expensive and do not guard against software failure.

This means that in most verticals, especially software-driven services, a high availability architecture makes a lot of sense. It is highly cost-effective compared to a fault tolerant solution, which cannot handle software issues in the same way.

High Availability vs Disaster Recovery

Similarly, it is important to mention the difference between high availability and disaster recovery here. Disaster recovery (DR), just like it sounds, is a comprehensive plan for recovery of critical operations and systems after catastrophic events.

However, if you have deployed a highly available and fault tolerant system, for example, why engage in this kind of planning?

DR is typically focused on getting back online and running after a catastrophic event. High availability is focused on serious but more typical failures, such as a failing component or server. A disaster recovery plan may cope with the loss of an entire region, for example, although both are related.

What is a Highly Available Load Balancer?

Typically, availability as a whole is expressed as a percentage of uptime. A highly available load balancer can achieve optimal operational performance through either a single-node deployment or through a deployment across a cluster. In a single-node deployment, a single load-balancing controller performs all administrative functions, as well as all analytics data gathering and processing. In a high availability load balancing cluster, additional nodes provide node-level redundancy for the load-balancing controller and maximize performance for CPU-intensive analytics functions.

Does The VMware NSX Advanced Load Balancer Offer Solutions for High Availability in Load Balancing?

The VMware NSX Advanced Load Balancer offers a solution which can be configured for high availability load balancing in a number of different modes. Controller High Availability provides node-level redundancy for Controllers. A single Controller is deployed as the leader node, then two additional Controllers are added as follower nodes. Service Engine High Availability provides service-engine-level redundancy within a service engine group. If a service engine within the group fails, high availability heals the failure and compensates for the reduced site capacity. Read more about VMware NSX Advanced Load Balancer’s Solutions for high availability in load balancing here: Overview of VMware NSX Advanced Load Balancer.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

HTTP Strict Transport Security (HSTS) uses a header to inform client browsers that this site should only be accessed through SSL/TLS. This feature is intended to mitigate man-in-the-middle attacks that can force a client’s secure SSL/TLS session to connect via insecure HTTP. HSTS has a duration setting that tells clients the SSL/TLS preference should remain in effect for the specified length of time. This setting will only activate on an application that is configured to terminate SSL/TLS.

If an application is set temporarily to support SSL/TLS and HSTS has been set, it cannot gracefully be downgraded back to HTTP. Client browsers will refuse to accept the site via HTTP. When HSTS is in effect, clients will not accept a self-signed certificate.