1 / 38

ASF Deployment View

ASF Deployment View. Server and Network Infrastructure Learning & Planning. Deployment View Purpose. 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.

rafiki
Download Presentation

ASF Deployment View

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASF Deployment View Server and Network Infrastructure Learning & Planning www.air-worldwide.com

  2. 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.

  3. 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.

  4. 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.

  5. Deployment View Roadmaps Learning Roadmap

  6. 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.

  7. What Is ASF?Services • The back-end ASF files provide discrete “services” each of which represent a software technology AIR has engineered.

  8. What Is ASF? Licensing • Which ASF services are accessible is determined by the ASF Licensing service.

  9. 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.

  10. 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.

  11. Server-Level ASF DeploymentStages • In a Stage 2 ASF deployment a second server is introduced to host the data sources, thereby improving performance.

  12. Server-Level ASF DeploymentStages • 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.

  13. Server-Level ASF DeploymentStages • 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.

  14. 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.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. Deployment View Roadmaps Implementation Roadmap

  25. 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.

  26. Collect Requirements Services • What application is the customer paying for? • What ASF services are required to support the application?

  27. 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?

  28. Collect Requirements Users • How many users will simultaneously access the application? • Does the application make use of resource-intensive asynchronous ASF services?

  29. Collect Requirements Resiliency • How concerned is the customer about availability?

  30. 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.

  31. 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.

  32. 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.

  33. 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.

  34. Layout InfrastructureLayout

  35. 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.

  36. Diagram ASF Deployment UML Deployment Diagram

  37. 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.

  38. Diagram ASF Deployment Network Deployment Diagram

More Related