reduced since the backup replicas do not execute instructions. 5.3.1.3 Passive VM Replication The state information of a VM instance is regularly stored on a backup. In case of a failure, another VM instance is commissioned, and it restores the last saved state. A backup can be configured to share the state of several VM instances (or it can be dedicated to a particular application), and the VM restart process can be performed based on a priority value assigned to each VM instance. This approach consumes the least amount of resources, but provides lower availability than the first two methods. 5.3.2 Low SOFTWARE FAILURE RATES AND ACCURATE FAULT DETECTION Some techniques for achieving low failure rate and accurate fault detection are described in this sec- tion. Many of these techniques can be realized using the capabilities of ONAP described in Chapter 7. 5.3.2.1 VF Protection from External Services VFs need to protect themselves from both incoming north- and south-bound services utilized by the VF. This means that VFs need to ensure incoming requests can be distributed between multiple instances of the VFs (i.e., load balancing) if needed to maintain both service availability and per- formance. VFs also need to implement throttling mechanisms to limit the negative impact to the VF from either malicious or errant requestors SO that the VF service is not compromised. South-bound VF interactions need to ensure isolation utilizing such mechanisms as multiple sets of thread pools. VFs also need to build these same capabilities into modules within the VF. The VF software should ensure any persistent state data (such as state tables, Java messaging service [JMS] queues, etc.) is replicated to redundant data stores to ensure service continuity in case of failure of the primary store/queue. The VF software should use redundant connection pooling to connect to any data source that can be switched between pools in an automated or scripted fashion to ensure high avail- ability of the connection to the data source. 5.3.2.2 V