Вы находитесь на странице: 1из 4

DEPLOYMENT GUIDE

Hazelcast IMDG on Azure:


Best Practices for Deployment
Hazelcast IMDG on Azure: Best Practices for Deployment
Deployment Guide

Hazelcast IMDG on Azure:


Best Practices for Deployment

This paper is targeted towards cloud architects and developers who gear up a Hazelcast IMDG application
from a physical environment to a virtual cloud environment, namely Microsoft Azure. Azure is Microsoft’s cloud
platform: a growing collection of integrated services like compute, storage, data, networking and application.
The goal of this paper is to highlight best practices for running Hazelcast applications on Azure Virtual
Machines.

Like most cloud services, Azure has certain limitations, for example, multicast is not supported. Moreover, the
network can fluctuate since data centers, physical machines, and even CPU are shared with other applications
in the cloud, most of which are unknown to the user. This results in a more unpredictable environment than
a traditional in-house data center. Hence, it is important to configure Hazelcast in a way which minimizes any
network outage or fluctuation.

In this paper:

TT An overview on the terminology and high-level architecture of Microsoft Azure


TT Guidance on a smooth deployment of Hazelcast on Azure Virtual Machines
TT Explanation of some of the high availability options on Azure Virtual Machines

Microsoft Azure
Microsoft Azure is an Internet-scale computing and services platform hosted in data centers managed or
supported by Microsoft. It includes many separate features with corresponding developer services which can
be used individually or together. An Azure virtual machine gives you the flexibility of virtualization without
spending the time and money to buy and maintain the hardware that hosts the virtual machine. However, you
do need to maintain the virtual machine - configuring, patching, and maintaining the operating system and
any other software that runs on the virtual machine.

Deployment Best Practices for Hazelcast IMDG on Azure


The following pages provide best practices and recommendations to deploy Hazelcast IMDG on Azure.

Which Instance Types to Choose

Hazelcast IMDG® is an in-memory data grid that distributes data and computation to nodes that are
connected with a network, making it very sensitive to the network. It is highly recommended to choose one of
the instance types that are listed as “Network optimized” for Hazelcast deployments. The table below lists the
specifications of Azure Virtual Machine instance types we recommend:

Network optimized: fast networking with InfiniBand support

Available in select data centers. Adds a 40Gbit/s InfiniBand network with remote direct memory access
(RDMA) technology. Ideal for Message Passing Interface (MPI) applications, high-performance clusters,
modeling and simulations, video encoding, and other compute or network intensive scenarios.

INSTANCE CORES RAM DISK SIZES

A8 8 56 GB Low to Moderate
A9 16 112 GB Low to Moderate

© 2018 Hazelcast Inc. www.hazelcast.com DEPLOYMENT GUIDE 2


Hazelcast IMDG on Azure: Best Practices for Deployment

Azure Regions

Azure operates out of 17 regions around the world. Geographic expansion is a priority for Azure because
it enables our customers to achieve higher performance and supports their requirements and preferences
regarding data location. Since Azure offers multiple regions, you can start Azure VM instances in any location
that meets your requirements.

Note: The suggested instance types (A8 and A9) are available only in some regions.

You can see the list of available regions and their locations in the table below. The regions in blue are the ones
that Network optimized (A8 and A9) instances are available in:

AZURE REGION Location

Central US Iowa
East US Virginia
East US 2 Virginia
US Gov Iowa Iowa
US Gov Virginia Virginia
North Central US Illinois
South Central US Texas
West US California
North Europe Ireland
West Europe Netherlands
East Asia Hong Kong
Southeast Asia Singapore
Japan East Saitama Prefecture
Japan West Osaka Prefecture
Brazil South Sao Paulo State
Australia East New South Wales
Australia Southeast Victoria

Configuring the Network for Cluster Communication

Since Hazelcast instances need to communicate with each other to operate, the appropriate network
configuration should be made among Azure VM instances. Every Azure VM instance is created in a Cloud
Service which will also be the DNS name to access. The public access is provided by this DNS name and the
port number assigned to the Azure VM instance. If VM instances are created in the same Cloud Service, all the
network traffic is allowed through assigned internal IPs.

For Hazelcast IMDG, you can choose one of two options to make it operate successfully:

TT Azure VM instances that lie in the same Cloud Service. With this option, you should configure Hazelcast
tcp-ip config with the internal IPs of the VMs.
TT Create the Azure VM instances on the same Virtual Network. With this option, Hazelcast tcp-ip config should
be configured with the Virtual Network IPs of the VMs.

© 2018 Hazelcast Inc. www.hazelcast.com DEPLOYMENT GUIDE 3


Hazelcast IMDG on Azure: Best Practices for Deployment

Network Latency

Since data is sent and received very frequently in Hazelcast IMDG applications, latency in network becomes
a crucial factor. In terms of latency, performance of the Azure cloud is not the same for each region and there
are vast differences in speed and optimization from region to region. It is a known fact that when you do not
pay attention to Azure regions, Hazelcast applications may run tens or hundreds times slower than necessary.
Below are some of the workaround to mitigate these problems:

TT Create a cluster only within a region. We do not recommend deploying a single cluster that spans across
multiple regions.
TT If a Hazelcast application is hosted on Azure VM instances in multiple Azure regions, the latency can be
reduced by serving the end users’ requests from the Azure region which has the lowest network latency.
Changes in network connectivity and routing result in changes in the latency between hosts on the Internet.
TT Simply move the deployment to another Region.
TT Test the network latency, as well as the downloading and uploading speeds, at a site like
http://cloudharmony.com/speedtest

Debugging

When and if needed, Hazelcast IMDG can log the events for the instances that exist in a region. To see what
has happened or trace the activities while deploying, change the log level in your logging framework to
FINEST or DEBUG. After this change, you can see whether the instances are accepted or rejected, as well as
the reason of rejection for the rejected instances in the generated log. Note that, changing the log level to one
of the mentioned levels may affect the performance of the cluster.

350 Cambridge Ave, Suite 100, Palo Alto, CA 94306 USA Hazelcast, and the Hazelcast, Hazelcast Jet and Hazelcast IMDG logos
Email: sales@hazelcast.com Phone: +1 (650) 521-5453 are trademarks of Hazelcast, Inc. All other trademarks used herein are the
Visit us at www.hazelcast.com property of their respective owners. ©2018 Hazelcast, Inc. All rights reserved.

Вам также может понравиться