// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
= Installing Apache Ignite in VMWare

== Overview

Apache Ignite can be deployed in virtual and cloud environments managed by VMWare. There are no specificities related to
VMWare; however, we recommend you have an Ignite VM pinned to a single dedicated host, which allows you to:

* Avoid the "noisy neighbor" problem when Ignite VM could compete for the host resources with other applications. This
might cause performance spikes in your Ignite cluster.
* Ensure high-availability. If a host goes down and you had two or more Ignite server node VMs pinned to it, then it could lead to data loss.

The following sections cover vMotion usage aspects for Ignite nodes migration.

== Cluster Nodes Migration With vMotion

vMotion provides migration of a live VM from one host to another. There are some basic principles Ignite relies on to
continue a normal operation after the migration:

* Memory state on the new host is identical.
* Disk state is identical (or the new host uses the same disk).
* IP addresses, available ports, and other networking parameters are not changed.
* All network resources are available, TCP connections are not interrupted.

If vMotion is set up and works in accordance with above mentioned rules, then an Ignite node will function normally.

However, the vMotion migration will impact the performance of the Ignite VM. During the transfer procedure a lot of resources
-- mainly CPU and network capacity -- will be serving vMotion needs.

To avoid negative performance spikes and unresponsive/frozen periods of the cluster state, we recommend the following:

* Perform migration during the periods of low activity and load on your Ignite cluster. This ensures faster transfer with
minimal impact on the cluster performance.
* Perform migration of the nodes sequentially, one by one, if several nodes have to be migrated.
* Set `IgniteConfiguration.failureDetectionTimeout` parameter to a value higher than the possible downtime for Ignite VM.
This is because vMotion stops the CPU of your Ignite VM when a small chunk of state is left for transfer. It will take X
time to transfer the chunk and `IgniteConfiguration.failureDetectionTimeout` has to be bigger than X; otherwise, the node
will be removed from the cluster.
* Use a high-throughput network. It's better if the vMotion migrator and Ignite cluster are using different networks to
avoid network saturation.
* If you have an option to choose between more nodes with less RAM vs. fewer nodes with more RAM, then go for the first option.
Smaller RAM on the Ignite VM ensures faster vMotion migration, and faster migration ensures more stable operation of the Ignite cluster.
* If it's applicable for your use case, you can even consider the migration with a downtime of the Ignite VM. Given that
there are backup copies of the data on other nodes in the cluster, the node can be shut down and brought back up after the
vMotion migration is over. This may result in better overall performance (both performance of the cluster and the vMotion
transfer time) than with a live migration.