Flexible Rollback Recovery in Dynamic Heterogeneous Grid

Computing
ABSTRACT

Large applications executing on Grid or cluster architectures consisting

of hundreds or thousands of computational nodes create problems with respect to
reliability. The source of the problems are node failures and the need for dynamic
configuration over extensive run-time. This paper presents two fault-tolerance
mechanisms called theft induced check pointing and systematic event logging. These
are transparent protocols capable of overcoming problems associated with both, benign
faults, i.e., crash faults, and node or subnet volatility. Specifically, the protocols base the
state of the execution on a dataflow graph, allowing for efficient recovery in dynamic
heterogeneous systems as well as multi-threaded applications. By allowing recovery
even under different numbers of processors, the approaches are especially suitable for
applications with need for adaptive or reactionary configuration control. The low-cost
protocols offer the capability of controlling or bounding the overhead. A formal cost
model is presented, followed by an experimental evaluation. It is shown that the
overhead of the protocol is very small and the maximum work lost by a crashed process
is small and bounded.

PROJECT DESCRIPTION

*) CLIENT

1) Account Creation
2) Cash Withdraw
3) Cash Deposit
4) Amount transaction to server
5) View transaction from Grid
 *) SERVER

1) Rollback Recovery
2) Process to Grid

*) GRID

1) Dynamic Grid Process

Account Creation:
Bank Manager can create Account for user via using their bank id.When
Authenticated Bank manager can process and create account. After creating an account manager
can activate their Account. After Activation only the user can processed using that Account id.

Cash Withdraw:
After Activation user or banker can withdraw their amount through using their
Account id and secret pin number

Cash Deposit:
After Activation user or banker can deposit their amount through using their Account
id and secret pin number

Amount transaction to server:

Here bank transaction to other bank is to been processed. The transaction Account id
checked to access their other bank. If account id is valid. Checks the Amount enter via user.
After finishing the procedure amount to be transfer to other bank server

View transaction from Grid

 After transaction Process, Admin can view transaction from other server db.if
transaction server gets failed (or) problem in maintance.client can be divert to grid Environment.

*) SERVER:

Roll Back Recovery:

Server can maintain db.if db gets failure. Server can choose dynamic grid server in
network configuration. If system are active form ip list. They choose active system from
dynamic setting. Here using semantic event logging back ups are send to other systems for
timely updating.

Process to Grid:

If server problem. Server can collect request from multiple client. If check for
personal db.if problem found in server. it will divert to selected grid server from client request.
But client can’t get particular ip for grid. Because it will grid server to be changed.

3. SYSTEM CONFIGURATION

3.1 HARDWARE CONFIGURATION

The hardware used for the development of the project is:

PROCESSOR : PENTIUM III 766 MHz

RAM : 128 MD SD RAM
MONITOR : 15” COLOR
HARD DISK : 20 GB
FLOPPY DRIVE : 1.44 MB
 CDDRIVE : LG 52X
KEYBOARD : STANDARD 102 KEYS
MOUSE : 3 BUTTONS

3.2 SOFTWARE CONFIGURATION

The software used for the development of the project is:

OPERATING SYSTEM : Windows 2000 Professional

ENVIRONMENT : Visual Studio .NET 2005
.NET FRAMEWORK : Version 2.0
LANGUAGE : C#.NET
WEB SERVER : Internet Information Server 5.0
BACK END : Sql server 2000
REPORTS : WebFormDataGridcontrol
5.1 INPUT DESIGN
5.2 OUTPUT DESIGN

5.3 DATABASE DESIGN

 The database design is a must for any application developed especially more
for the data store projects. Since the chatting method involves storing the message in the table
and produced to the sender and receiver, proper handling of the table is a must.
In the project, admin table is designed to be unique in accepting the username and the
length of the username and password should be greater than zero.

5.4 Data Flow Diagram:

LEVEL 0:

Bank 1

Transaction Data Base

Bank 2

Bank 3

LEVEL 1:

Bank 1 Login Account Creation

Actuation

Cash with Draw

Cash Deposit
 View Transaction

LEVEL 2:

Bank 2 Login Account Creation

Activate

Roll Back

Semantic Event Logging

DB1
THEFT INDUCED Dynamic
Selected DB
CHECK POINT

Listen
DB2

D D
B B
Fetch
0
h