Internet Infrastructure

Transcription

1 Internet Infrastructure A. Mariën (c) A. Mariën 1

2 HA DR - BC High Availability Resilience of your infrastructure Uptime during agreed windows of 9x,xx% Disaster Recovery Recovery capability Key objectives to meet: Recovery Point Objective (RPO): how much loss is acceptable? Recovery Time Objective (RTO): how long may it take to recover? Business Continuity Business continuity plan describes how to continue business despite major hurdles (office buildings unavailable, computer rooms inaccessible, power grid outage ) (c) A. Mariën 2

3 HA LB DR back-up - BC High Availability User point of view The IT functions are highly available to their users Load balancing IT point of view Efficient use of available infrastructure Disaster recovery IT point of view Returning back to acceptable situation after a major incident Back-up IT point of view Safe copies of data to recover from data loss Business continuity Business point of view Ensuring business can continue because critical functions are operational (c) A. Mariën 3

4 Disaster recovery business continuity Disaster Recovery Respond to disasters System down Disk crash Measures: Recovery point objective the maximum time period in which data might be lost loose 1 hour of data Recovery time objective The amount of time the business can be without the service, without incurring significant risks or significant losses system unavailable for 1 hour Options Back-up/restore Business continuity Major outage IT site unreachable, destroyed Survival mode: minimal functions to survive, able to continue business Provide critical operational support Options: Physically separated sites Rented locations Home working Types: Hot standby: up and running in no time Cold standby: capability Infra only: deploy when needed (c) A. Mariën 4

5 HA LB DR - back-up - BC High Availability User point of view The IT functions are highly available to their users Load balancing IT point of view Efficient use of available infrastructure Disaster recovery IT point of view Returning back to acceptable situation after a major incident Back-up IT point of view Defines recovery points Supports recovery of lost data (files disks major storage facilities) Business continuity Business point of view Ensuring business can continue because critical functions are operational Switch to manual processes, postpone processing (c) A. Mariën 5

6 Topic: High Availability (c) A. Mariën 6

7 High Availability Key property: availability high is relative Important to determine correctly Cost of unavailability Business continuity: how long can one accept unavailability? Key concept: single point of failure: SPoF SPoF examples Network (one ISP, one network card, one switchboard, ) Power (one switch, one provider, ) Physical access (one door, one gate, one road ) People (only one person knows how to ) Principle: No single point of failure Major method to achieve: redundancy (c) A. Mariën 7

8 HA: active - passive Capacity: 100% Passive Capacity: 70% Active Hartbeat link Active Capacity: 100% Active Capacity: 70% 100% overcapacity 100% OK after switch 40% overcapacity 70% OK after switch Load balancing (c) A. Mariën 8

9 HA: crosses (c) A. Mariën 9

10 HA: Two trains / streets (c) A. Mariën 10

11 Back-up Create copy of data Full incremental Need support for incremental operations Son - father grandfather principle make and keep back-up daily (RPO one day) Keep weekly (RPO one week) Keep monthly (RPO one month) Versioned file system Keeps last n versions Avoids intra-day losses (c) A. Mariën 11

12 Back-up - archiving Back-up Use: protection against data modification Delete Update Redundant copy Full incremental Mostly On-line Use: restore archiving Use: Reduce on-line storage needs Record keeping (requirement) Master data Incremental Mostly off-line Use: search (c) A. Mariën 12

13 Topic: Load balancing (c) A. Mariën 13

14 Load balancing Solve resource/capacity problem One system cannot cope with load Put bigger system in place Put a cluster in place Use multiple systems: load balancing (c) A. Mariën 14

15 Load balancing Virtual server Server 1 client LB Server 2 server3 Server (c) A. Mariën 15

16 Load balancer Hides the fact that there are multiple servers Presents itself as THE server (virtual server) Determines best system to handle Best system to handle requests based on request and system information Expected load Current load of systems But: may not look at either, and count on statistical balancing (round robin) (c) A. Mariën 16

17 Load balancer: dealing with stickyness Servers may need to get multipel requests to not brake the transparency, or just plain work Issues: Sessions, state Example: IP packet of one TCP session must go to same serverin a standard implmentation http sessions must be handled by the same server for vanilla web servers (c) A. Mariën 17

18 Sticky sessions First req First req Next req Next req (c) A. Mariën 18

19 State in client stateless operation First req Next req (c) A. Mariën 19

20 Client state Need to communicate all of the state each time Overhead size limitations Multiple requests to different servers => independent state management possible (possible conflicts) Some state data is critical for server security Logged-in user, authorizations State protection: Protect confidentiality, integrity Encryption, one key to manage them all? (c) A. Mariën 20

21 Load balancing Servers have resource limitations Objectives: Scalability Servers have resource limitations, a single server has maximal load points OS level (multiprocessor, clusters): expensive Add or remove additional servers transparently Availability Replace defective components: only subset of users impacted But not High-Availability (HA): other measures required Secondary Transparency Virtual server (c) A. Mariën 21

22 Load Balancing solutions Effective load balancing: Measure availability Health monitoring System availability: ping Service availability: service ping Measure load Load = resource usage: CPU, disk,... Transparency Server side state Managed on a server instance: requires persistence Each packet /message of connection to same server Problem with higher level sessions (higher than LB mechanism) State distribution Central state store (new problem point) Cost of state migration (c) A. Mariën 22

23 General principle Client Client Client1 Client2 C-S C-S C1-S C2-S Server Virtual Server Map: C-S:VS-RS Virtual Server C1-S:VS-Rsa C2-S:VS-RSb VS-RS Real Server VS-RSa Real Server a VS-RSb Real Server b (c) A. Mariën 23

24 Load balancing systems Four main hooks for network load balancing: ARP Different MACs for single IP NAT Different mappings for same IP DNS round robin Different IPs for same DNS name Proxy Different back-ends for same proxy request Many vendors of solution: Alteon, F5, Cisco, Resonate, Radware, (c) A. Mariën 24

25 ARP IP address: map one IP to multiple MAC addresses Keep track of sessions: which MAC for which TCP session Note: optimization Short requests, long replies: only request via load balancer, replies: direct Examples: Cisco local director, F5 BIG IP (c) A. Mariën 25

26 Client Router ARP: roundtrip > > M Rout ->M LB-L LB M LB-R ->M sysi M LB-L M LB-R M sysi Sys i < M rout <- M sysi (c) A. Mariën 26

27 Client Router ARP: routing Arp: MAC LB -> LB noarp Sys i (c) A. Mariën 27

28 NAT based load balancing Virtual IP incoming Translate to multiple internal IP addresses Keep session state FW-1, BIG IP (c) A. Mariën 28

29 Client Router NAT: roundtrip :x-> -> :80 LB :x-> -> :80 Sys i Set up client connection Decide back-end system Translate all packets :x-Sys i (c) A. Mariën 29

30 DNS round robin Do not allow caching of DNS IP mapping Hand out IPs in round-robin mode Statistical loadbalancing Cisco Distributed Director, 3DNS (c) A. Mariën 30

31 Proxy Connections forwarded to different IPs HTTP reverse proxies Host: a = server a/ Host: b = server b Map: /images: /doc: (c) A. Mariën 31