Academia.eduAcademia.edu

Figure 11 – uploaded by Shilpa Shilpa

See full PDFdownloadDownload figure
Fig. 9. The LLFT fault tolerance architecture proposed in (Zhao et al., 2010).

Figure 9 The LLFT fault tolerance architecture proposed in (Zhao et al., 2010).

Related Figures (17)

In this paper, first, methods of creating the capacity of Fault Tolerance in Cloud computing are pointed out. Subsequently, policies of the implementation of these methods are stated. Next, the offered archi- tectures for the production of such capacity in Cloud computing is delineated and, finally, they are compared in terms of the type of policy or policies employed in the architecture and the method of fault detection and fault recovery. Keywords: Cloud computing Fault tolerance architecture Proactive Reactive
In this paper, first, methods of creating the capacity of Fault Tolerance in Cloud computing are pointed out. Subsequently, policies of the implementation of these methods are stated. Next, the offered archi- tectures for the production of such capacity in Cloud computing is delineated and, finally, they are compared in terms of the type of policy or policies employed in the architecture and the method of fault detection and fault recovery. Keywords: Cloud computing Fault tolerance architecture Proactive Reactive
MI \flldils Cl dl., 2Ui1, LIU Ct dl, 2U1o, lal Miva lll alld OLEH, 2001), Byzantine fault tolerance architecture is introduced. This architecture is also one of the reactive methods. Replication policy is used in this architecture which is considered as the fundamental architecture of the BFT-Cloud. The method in this architecture includes three different phases. In the first phase, the same input is distributed between nodes and the output should be sent to all the reviewed node in the set. The reviewed set includes the primary and backup nodes. Obviously, we expect that the same input in different nodes produces the same output because the process is same on all nodes. Different output will be produced only in the case of a faulty node. The first stage is continued by broadcasting the output of each node to the neighboring nodes and the other members of the reviewed nodes. At the end of the first phase, each node should form the output vector of the neighbors. In the second phase, each of the nodes broadcasts the made vector in the previous step between neighboring nodes. This output vector considers Gossip architecture is introduced to improve the performance of the Byzantine architecture (Lim et al., 2013). This structure is a part of reactive method which exploits replication policy to detect a fault and creating fault tolerance capability in the cloud com- puting system. In this architecture, each of the cloud machines has a decision vector. At every stage of the network operation, each node selects a neighbor node and the two nodes are required to update their decisions vector together. The size of the decision vector depends on the number of neighboring nodes. Since, the
MI \flldils Cl dl., 2Ui1, LIU Ct dl, 2U1o, lal Miva lll alld OLEH, 2001), Byzantine fault tolerance architecture is introduced. This architecture is also one of the reactive methods. Replication policy is used in this architecture which is considered as the fundamental architecture of the BFT-Cloud. The method in this architecture includes three different phases. In the first phase, the same input is distributed between nodes and the output should be sent to all the reviewed node in the set. The reviewed set includes the primary and backup nodes. Obviously, we expect that the same input in different nodes produces the same output because the process is same on all nodes. Different output will be produced only in the case of a faulty node. The first stage is continued by broadcasting the output of each node to the neighboring nodes and the other members of the reviewed nodes. At the end of the first phase, each node should form the output vector of the neighbors. In the second phase, each of the nodes broadcasts the made vector in the previous step between neighboring nodes. This output vector considers Gossip architecture is introduced to improve the performance of the Byzantine architecture (Lim et al., 2013). This structure is a part of reactive method which exploits replication policy to detect a fault and creating fault tolerance capability in the cloud com- puting system. In this architecture, each of the cloud machines has a decision vector. At every stage of the network operation, each node selects a neighbor node and the two nodes are required to update their decisions vector together. The size of the decision vector depends on the number of neighboring nodes. Since, the
Fig. 2. The BFT-Cloud fault tolerance architecture described in (Zhang et al., 2011). Fig. 1. The FT_Cloud fault tolerance architecture introduced in (Zheng et al., 2010).
Fig. 2. The BFT-Cloud fault tolerance architecture described in (Zhang et al., 2011). Fig. 1. The FT_Cloud fault tolerance architecture introduced in (Zheng et al., 2010).
Fig. 4. Stage of node results in Gossip architecture (Lim et al., 2013). Fig. 3. Stage of node calculation in Gossip architecture (Lim et al., 2013).
Fig. 4. Stage of node results in Gossip architecture (Lim et al., 2013). Fig. 3. Stage of node calculation in Gossip architecture (Lim et al., 2013).
Obviously, this architecture improves the reliability of fault detection to 50%. Because in the Gossip architecture, if 2k+1 node be available in the network, k faulty node can be identified. For example, if we have 200 machines under the cloud computing infrastructure, almost 100 faulty machines can be identified by using the Gossip architecture. This architecture is a standard for parallel programming. Implementation of high-level protocols makes possible to use the relationships between processes and process management. It is also possible to create a new implementation by rewriting only low-level functions. MPI has two layers. The top layer is inde- pendent of the infrastructure communication and the bottom layer is called SSI and specifies that whether the backup of the
Obviously, this architecture improves the reliability of fault detection to 50%. Because in the Gossip architecture, if 2k+1 node be available in the network, k faulty node can be identified. For example, if we have 200 machines under the cloud computing infrastructure, almost 100 faulty machines can be identified by using the Gossip architecture. This architecture is a standard for parallel programming. Implementation of high-level protocols makes possible to use the relationships between processes and process management. It is also possible to create a new implementation by rewriting only low-level functions. MPI has two layers. The top layer is inde- pendent of the infrastructure communication and the bottom layer is called SSI and specifies that whether the backup of the
Fig. 5. The MPI fault tolerance architecture introduced in (Kaur and Kinger, 2013).
Fig. 5. The MPI fault tolerance architecture introduced in (Kaur and Kinger, 2013).
‘ig. 6. The FTM fault tolerance architecture proposed in (Kaur and Kinger, 2013). checkpoint is needed or not. In this architecture, the faulty node sends MPI Request to the other nodes. The number of nodes that have received the faulty node request sends the positive response of the request to the faulty node and the faulty node migrates the program running from the last checkpoint onward to the healthy node using checkpoint/restart and job migration techniques.
‘ig. 6. The FTM fault tolerance architecture proposed in (Kaur and Kinger, 2013). checkpoint is needed or not. In this architecture, the faulty node sends MPI Request to the other nodes. The number of nodes that have received the faulty node request sends the positive response of the request to the faulty node and the faulty node migrates the program running from the last checkpoint onward to the healthy node using checkpoint/restart and job migration techniques.
Fig. 8. The Magi-Cube fault tolerance architecture proposed in (Feng et al., 2012).
Fig. 8. The Magi-Cube fault tolerance architecture proposed in (Feng et al., 2012).
Fig. 7. The FTM-2 fault tolerance architecture proposed in (Jhawar et al., 2012). FTWS architecture that is shown in (Jayadivya et al.) has pro- vided fault tolerance using replication and restart techniques while considering the priority of tasks. This architecture schedules the workflows with a deadline in the presence of faults. It should be noted that repeating things depends on an exploratory and metric measurement that should be determined in the form of trade off from among the factors of the techniques used in The architecture introduced in (Zhao et al., 2010) which has been called LLFT provides fault tolerance with low latency. This arc hitecture has provided FT capacity for developing Distributed Application or Data Centers. LLFT has benefited from Leader/Fol- lower Replication approach. There is minimum end to end latency and replica transparency is very robust. When a fault occurs, LLFT is reconfigured and recovery mechanisms make sure that a backup ver: sion exists. Then, the state is transferred from the existing rep to ica to new replica. One of the most important tasks of LLFT is robustly maintain the compatibility of different duplicate copies. On the other hand, the operations should be synchronized so that minimum end to end latency will be achieved (Fig. 9).
Fig. 7. The FTM-2 fault tolerance architecture proposed in (Jhawar et al., 2012). FTWS architecture that is shown in (Jayadivya et al.) has pro- vided fault tolerance using replication and restart techniques while considering the priority of tasks. This architecture schedules the workflows with a deadline in the presence of faults. It should be noted that repeating things depends on an exploratory and metric measurement that should be determined in the form of trade off from among the factors of the techniques used in The architecture introduced in (Zhao et al., 2010) which has been called LLFT provides fault tolerance with low latency. This arc hitecture has provided FT capacity for developing Distributed Application or Data Centers. LLFT has benefited from Leader/Fol- lower Replication approach. There is minimum end to end latency and replica transparency is very robust. When a fault occurs, LLFT is reconfigured and recovery mechanisms make sure that a backup ver: sion exists. Then, the state is transferred from the existing rep to ica to new replica. One of the most important tasks of LLFT is robustly maintain the compatibility of different duplicate copies. On the other hand, the operations should be synchronized so that minimum end to end latency will be achieved (Fig. 9).
Fig. 10. The LLFT fault tolerance architecture proposed in (Xiaoyi Lu et al., 2010).
Fig. 10. The LLFT fault tolerance architecture proposed in (Xiaoyi Lu et al., 2010).
Fig. 11. The FTWS fault tolerance architecture proposed in (Jayadivya et al.).
Fig. 11. The FTWS fault tolerance architecture proposed in (Jayadivya et al.).
Fig. 12. The FTWS fault tolerance architecture proposed in (Machida et al., 2011).
Fig. 12. The FTWS fault tolerance architecture proposed in (Machida et al., 2011).
Fig. 14. The PLR fault tolerance architecture proposed in (Egwutuoha et al., 2012).
Fig. 14. The PLR fault tolerance architecture proposed in (Egwutuoha et al., 2012).
Fig. 13. The AFTRC fault tolerance architecture introduced in (Sudha Lakshmi, 2013).
Fig. 13. The AFTRC fault tolerance architecture introduced in (Sudha Lakshmi, 2013).
Comparison of the applied policies in each of the architectures.
Comparison of the applied policies in each of the architectures.
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved