www.air-worldwide.com asf deployment view server and network infrastructure learning & planning

www.air-worldwide.com

ASF Deployment View

Server and Network Infrastructure Learning & Planning

© 2005 AIR Worldwide Corporation CONFIDENTIAL

Deployment ViewPurpose

The Deployment View shows the hardware infrastructure upon which an ASF installation is deployed and describes which parts of the installation are deployed to which physical pieces of hardware.

The Deployment View produces several end products A set of best-practice infrastructure layouts which have undergone

software/hardware platform validation. A deployment diagram based on the validated platforms and tailored to the

budget, reliability, availability, scalability, security and preexisting network/computing resources constraints of the deployment.

Methodologies for collecting and analyzing application and hardware performance metrics.


Deployment ViewDesign Criteria

Scalability Small ASF deployments should require minimal or no additional network

hardware. Steady, incremental additions of hardware to an ASF deployment should

allow growth from small to enterprise-level deployments. Growth should be customizable per ASF service.

Resiliency Transition of ASF services to a redundant deployment should be

straightforward and utilize standard network load balancing methods. Downtime due to unexpected application behavior should be reduced by

providing a network environment where in-situ analysis of traffic is possible.


Deployment View Roadmaps

We will employ two roadmaps to describe the ASF Deployment View. The roadmaps will guide us through the topics necessary to understand the ASF Deployment View from both conceptual and implementation vantages

The Learning roadmap will describe the high level ASF building blocks and how they interact with IT equipment. Topics in this roadmap are generalized and do not provide specifics about the deployment view.

The Implementation roadmap takes the generalized topics discussed in the Learning roadmap and describes how to convert them into an ASF deployment.


Deployment View Roadmaps Learning Roadmap

What is ASF? ASF ServersNetworking ASF

Servers

Files

Licensing

Connectivity

Load balancing

Location

Access

Services

Maturation Stages

Service Clustering

Security

Sub-Topics

Communications


What Is ASF?Files

ASF is a set of installable files which provide the back-end functionality of the ASF Presentation (PL), Business (BL) and Data (DL) layers.

Installation of the ASF core files on a computer makes the computer an ASF-aware server.

A full ASF deployment consists of One or more computers with the back-end ASF files Specific-function 3rd party software such as the host OS, IIS, RDBMS or a map

server.

All ASF back-end files are installed on all ASF servers.


What Is ASF?Services

The back-end ASF files provide discrete “services” each of which represent a software technology AIR has engineered.

ASF Installation Files

Presentation Layer Business Layer Data Layer

Address Service

Hazard Analysis Service

Map Service

Passport Service

Communications Service

Replacement Cost Service

PushPin Service

Loss Analysis Service

Exposure Analysis Service

Guideline Service

Report Service

Bulk Data Service

User Interface Hazard Provider

Exposure Provider

Loss Provider


What Is ASF? Licensing

Which ASF services are accessible is determined by the ASF Licensing service.


ASF ServersGrowth Stages

An ASF deployment matures through four broad stages. Progression from one stage to the next occurs for a number of reasons

Enhancing performance of heavily used services Providing redundancy for critical services Providing segmentation of services in an ASP environment

The exact pattern of growth is dependant on the mix and utilization of ASF components installed. However, maturation of the deployment will generally follow the four stages.

Depending on requirements, stages may be skipped.


Server-Level ASF DeploymentStages

In a Stage 1 ASF deployment, all software (ASF, necessary 3rd party software and data sources) is installed on a single server. This stage is only suitable for the smallest of deployments.

General ASF Server

ExtSW

DataSource



In a Stage 2 ASF deployment a second server is introduced to host the data sources, thereby improving performance.

General ASF Server

DataSource

ExtSW

Data Source Server



In a Stage 3 ASF deployment we continue to improve performance by moving heavily-used or resource-intensive ASF services to new “tasked” servers. Both PL and BL services may be tasked.

General ASF Server

DataSource

ExtSW

Data Source Server

Tasked ASF Server(AWS)

Tasked ASF Server(Loss)



In a Stage 4 ASF deployment, we begin to cluster tasked ASF servers to provide resiliency and further performance gains. Additionally, data source servers may be partitioned. A very large scale ASF deployment will follow this pattern.

General ASF Server

DataSource

ExtSW

Data Source Server






Server-Level ASF DeploymentService Clustering

Individual ASF services hosted by more than one tasked server are called ASF service clusters.

A large-scale deployment may contain multiple ASF service clusters. Because multiple server can in an ASF cluster can fulfill a request, requests

to ASF service clusters must be load balanced.




Loss Cluster

General ASF Server Data Source Server

ASF DeploymentHazard Cluster

PassPort Cluster

AWS Cluster


Server-Level ASF DeploymentService Clustering

It is important to note that tasked ASF servers may still provide support for any AFS service.

It is not the case that a tasked ASF server can, or should, host only the one service tasked to it.

A super-mesh of ASF services may be problematic.


Networking ASF ServersConnectivity

ASF servers operate on any 100 Mbps or better Ethernet LAN. ASF servers must be able to communicate freely on any TCP/IP port.

No firewalls, routers, proxies or IDS/IPS devices should be placed between ASF servers.

Firewalls, etc. may be placed in between ASF servers and the data source servers or the clients.


Networking ASF Servers Communications

ASF servers communicate via TCP/IP.

All ASF services on an ASF server listen on a single IP address.

Individual ASF services listen on pre-defined TCP ports in the range 20000-30000.

ASF Server(10.0.0.10)

Hazard Service (port 20001)

PushPin Service (port 20002)

Loss Service (port 20003)

Passport Service (port 20004)

...


Networking ASF Servers Communications

The ASF Service Manager service is responsible for shuttling inbound requests from clients to the appropriate ASF service for processing.

The service manager makes a request for a ASF service via a URL & port i.e., server1.company.com:20003.

Because every ASF server has the Service Manager service, a Stage 3 and above deployment has one or more ASF servers designated as “lead” Service Manager servers. All inbound requests to ASF will be funneled through the lead Service Manager service servers.


Networking ASF ServersLoad Balancing

Earlier we introduced the idea of ASF service clusters, a single ASF service tasked to multiple servers.

Once service clusters are introduced, there needs to be a method of determining which server in a service cluster should respond to an incoming request. Load balancing provides this service.

Load balancing for ASF service clusters can be put into two categories Synchronous, quick-response services Asynchronous, long-running services

Load balancing of synchronous service clusters is handled by Layer 4/7 network load balancers (NLB).

Load balancing of asynchronous service clusters is handled by the ASF Job Manager service.


Networking ASF ServersLoad Balancing

Layer 4/7 NLB can be costly and require IT knowledge to maintain. To prevent smaller ASF installations from having to purchase NLB

equipment in the early stages of ASF deployment growth, ASF will include built-in NLB. A transition to hardware-based NLB is intended once the deployment reaches a certain size.

Load balancing of asynchronous service clusters will be managed by the ASF job manager regardless of deployment size.

Because there are multiple, bi-directional communications possible between ASF service clusters, a one-arm/side-arm hardware NLB setup is recommended.


Networking ASF ServersLocation

It is expected that all ASF servers (not necessarily including data sources and clients) will be located in the same LAN segment or security zone.

External or untrusted access to the ASF deployment should be protected by network security devices such as Layer 3/4/7 firewalls and IDS/IPS.


Networking ASF Servers Security

Security is not generally thought of as part of the communication between components within an application.

ASF (may) include a security infrastructure designed to transparently intercept and A/A intra-ASF communications.

Security into ASF from external clients should be provided at the edge by standard network security devices.


Networking ASF Servers Access

At a minimum, clients need to be able to access the ASF deployment via whatever mechanism the client requires.

It is also possible that external (Internet) clients will access the deployment. AWS is intended to provide the gateway to an ASF deployment for external clients.

AWS services may also need to make calls out to the Internet to fulfill requests.


Deployment View Roadmaps Implementation Roadmap

Collect Requirements

Layout Infrastructure

Diagram ASFDeployment

Services

Resiliency

Single/ASP

Data

Users

Sub-Topics

Budget

Needs UML Diagram

Network Diagram

Staging deployment diagrams

Staging production diagrams

ValidatePlatforms

Performance

Stability

Audience

Scalability Layout


Validate Platforms

Platform validation helps answer several core questions about ASF Deployment

Which combinations of ASF/3rd party software are supported/recommended?

What is the relationship between server/network hardware and performance on a per-ASF service basis?

What level of scalability can be expected for a particular ASF service? What are the minimum server and network specifications necessary to

deploy ASF? How many/much of X is required to support ASF performance criteria Y?

Platform validation will define best-practice baseline infrastructure layouts valid for a variety of audiences. These become very useful when the customer has less-than-clear requirements.


Collect Requirements Services

What application is the customer paying for? What ASF services are required to support the application?


Collect Requirements Data

How much existing customer data needs to be imported to allow use of the application?

How much new data is the customer expected to generate? How much transient data is the customer expected to generate? Will the customer require data warehousing?


Collect Requirements Users

How many users will simultaneously access the application? Does the application make use of resource-intensive asynchronous

ASF services?


Collect Requirements Resiliency

How concerned is the customer about availability?


Layout InfrastructureNeeds

With the requirements data collected, we can begin to layout an infrastructure to meet the customer’s business requirements.

It has traditionally been difficult to avoid starting each new customer installation at square one. Decision trees and validated platforms will help alleviate this problem.

The decision tree will incorporate the requirements and lead to “must have” ASF service cluster.

If the customer’s requirements call for large loss analyses which must complete in < 24 hours, the decision tree would indicate a Loss Service cluster is required.

Availability concerns would lead the decision tree to suggest the creation of a lead Service Manager cluster and so on.


Layout InfrastructureNeeds

Knowing the service cluster needs, the platform validation data is consulted and a server layout is created.

The platform validation data will determine how may servers are needed for the deployment and what role in the ASF environment each server will play.

The network layout is then determined by the server layout. At the end a deployment layout is produced.


Layout InfrastructureBudget

The infrastructure layout must meet budgetary requirements as well as business requirements.

It may be necessary to scale back the infrastructure plan to meet budgetary constrains.


Layout InfrastructureLayout

With a manifest of servers and what they will be used for in hand, we can create a basic deployment layout.

A layout is essentially a list of server and network equipment stereotypes to be used in the deployment, each labeled with the role it will play inside the ASF environment.

In our example, the customer requirements have lead to the need for Loss and Hazard service clusters, Map services and redundant lead Service Managers/PL services.


Layout InfrastructureLayout

ASF Server

Data Source Server

ASF Server

MapsLead Service ManagerPL

Loss Analysis

ASF Server

Loss Analysis

ASF Server

Hazard AnalysisLead Service ManagerPL

ASF Server

Hazard Analysis

HardwareNLB


Diagram ASF Deployment

Finally we are ready to create functioning ASF deployment diagrams. Deployment diagrams formalize the deployment specifics, combining all

information about requirements, layout and application flow. ASF deployment diagrams are created using complimentary UML

diagrams, network diagrams and application flow diagrams.


Diagram ASF Deployment UML Deployment Diagram

<<PC Server>>Server-ASF2-3

{DiskSpace=30 GB,CPU=Intel Xeon 3.0 GHz,

CPUCount=1, RAM=1 GB,

ASFRoles= Loss Analysis,,IP=10.0.0.3-4}

<<Vendor>>Microsoft Windows Server 2003

SP1

<<Binary>>ASFClasses : AllClasses (2.0)

<<PC Server>>Server-ASF-DS1



IP=10.0.0.9}

<<Vendor>>Microsoft SQl Server 2000 SP3a


SP1

<<PC Server>>Server-ASF1



ASFRoles= Maps;LeadServiceMgr;UI,IP=10.0.0.2}


<<Vendor>>Microsoft IIS 6.0


SP1

<<Vendor>>MapInfo MapExtreme (6.5)




ASFRoles= Hazard Analysis,IP=10.0.0.5}


SP1





ASFRoles= Hazard Analysis,UI,IP=10.0.0.6}


SP1


<<Vendor>>Microsoft IIS 6.0

<<PC Client>>Client-PC1

{DiskSpace=10 GB,CPU=Intel P4 2.0 GHz,

RAM=512 MB}

<<Binary>>ASFClientComm : HelloBackEnd

(2.0)

<<Vendor>>Microsoft Windows XP SP2


Diagram ASF Deployment UML Diagram

Note that a UML diagram is difficult to use due to ASF’s highly distributed nature.

UML diagrams best for laying out server hardware specifics and identifying software components to be installed.

Details about which roles each ASF server plays are difficult to visualize.


Diagram ASF Deployment Network Deployment Diagram

Client

Server-ASF1(10.0.0.2)

Server-ASF-DS1(10.0.0.7)





Network

NLB Clusters

VIP 10.0.0.100 (Hazard)Server-ASF4Server-ASF5

VIP 10.0.0.101 (UI)Server-ASF1Server-ASF5

VIP 10.0.0.102 (Lead SM)Server-ASF1Server-ASF5

Switch

HardwareNLB

www.air-worldwide.com asf deployment view server and network infrastructure learning & planning

Documents