Server Iron Hands-on Training

Transcription

1 Server Iron Hands-on Training

2 Training Session Agenda Server Iron L4 Solutions Server Iron L7 Solutions Server Iron Security Solutions High Availability Server Iron Designs 2

3 Four Key Reasons for Server Iron Layer 4-7 Solutions Performance Better Server Utilization Faster Response Times Accelerate Performance by Offloading to Server Iron Security Server Protection for Uptime Application Level to Protect Sensitive Data Access Control Critical IP Applications Availability Maintain Service Even when Servers Go Down Recover Service from Complete Site Failures Scalability Keep up with Growing Traffic by Incrementally Adding Servers Spread Servers Geographically 3

4 Server Iron Basics Server Farm Operation All Users Connect to Server Iron ONLY Using a Virtual IP Address This IP Address is like the *Common* Call Center Number (Toll Free Number) Real Servers do Actual Application Processing on a Private IP Subnet Similar to Call Center Operators with their Own Direct Phone # Extension Server Iron Distributes Connections and Checks Health of Servers Real Servers Server Iron Clients IP Network VIP = GW IP = Default Gateway = Load Balancer IP 4

5 Stateful Load Balancing and Session Table All Packets on Same Connection go to Same Server [Stateful Forwarding] Session Table Maintains Mapping New Connections go to *Best* Server Depends on Load Balancing Action and Server Load Conditions Src. IP Dest. IP Src. Port Dst. Port Server RS RS RS Session Table Server Iron Clients IP Network VIP = GW IP = Real Servers

6 Server Health Check Basics Server Iron Sends Periodic Messages to Real Servers Layer 4 TCP Health Check Layer 4 UDP Health Check ARP: Request ARP: Reply ICMP: Echo Request ICMP: Echo Reply SYN SYN-ACK RST* ARP: Request ARP: Reply ICMP: Echo Request ICMP: Echo Reply UDP Probe ICMP Unreachable *some application may log an error message HTTP Layer 7 Health Check Request a Web Page GET HTTP/1.0 /index.html Server Status 200 OK FIN RST 6

7 Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 7

8 Layer 4 Server Load Balancing Example Problem High Availability and Scalability for Web Servers Requirements Distribute Load to two HTTP Web Servers based on Health Monitoring Solution Server Iron Layer 4 Load Balancing Configuration Now Let us Build a Configuration for this Scenario 8

9 Step 1: Define Virtual Server IP and Port on ServerIron Call Center Contact # Define a Virtual IP Address [Layer 3 Contact Information] > server virtual <name> <IP address> > Example: server virtual vs Define a Virtual Port (TCP/UDP) for Application Access > port <application port #> > Example: [Other Port #s can be Provided as Well] Define the Load Balancing Method > server predictor <predictor name> > Example: server predictor round-robin > Default Predictor is Least Connections [Leave it Alone] > Common Predictors: Round Robin, Least Connections, Weighted 9

10 Step 2: Define Real Server IP and Port Call Center Operator Extensions Define a Real IP Address [Layer 3 Contact for Real Server] > server real <name> <IP address> > Example: server real rs Define a Real Port (TCP/UDP) for Application Access > port <application port #> > Example: port 80 Enable Health Check per Real Server > port <application port #> keepalive > Example: keepalive > You can Rely on Global Health Checks Profile as Alternative 10

11 Step 3: Bind Virtual and Real Server Information Map Call Operator Extensions Binding Virtual Port to Real Servers/Ports Establishes the Link Between *Point of Contact* and *Server Resources* Under Virtual Server Definition, Bind Real Servers and Ports bind http rs1 80 rs2 80 Application Port of First Real Server Name of First Real Server Similar Definition of all Real Servers Virtual Port of Virtual Server Virtual IP = Real IP = Virtual Port 80 Real Port 80 Port Binding 11

12 We have a Layer 4 Server Load Balancing Configuration Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server real rs keepalive server real rs keepalive server virtual vs predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway That s All Folks Define Real Server #1 & #2 Enable Periodic Health Checks Define Virtual Server Modify Default Load Balancing Method Bind Virtual and Real Servers, and Application Ports Source-IP is required when VIP and Real Servers are on Different Subnets (Hide Real Addresses) > server source-ip <ip-address> <mask> <gateway> > server source-ip NOT Required with Router Code because you can Route between Subnets 12

13 Make it a Little Fancy Change Health Checks Frequency and L7 Web Page Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server port 80 tcp keepalive 10 2 server real rs url GET /default.html keepalive server real rs url GET /default.html keepalive server virtual vs predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Changing Health Check Interval for Real Port > server port 80 > tcp keepalive <interval> <retries> > tcp keepalive 10 2 Add L7 HTTP Health Check under Real Port > server real rs > Port http url GET/sales.html 13

14 What Happens Next when Clients Start Connecting? Now the Configuration on ServerIron is Ready for Traffic Call Center is Open for Operation ServerIron Creates Session Table Entries for Each Connection Each Entry Uniquely Identifies a Flow and its Server Mappings All Packets Matching an Entry Forwarded to Same Real Server Each TCP Connection Consists of Four Sessions Two Each for Forward and Reverse Directions of the Flow Displaying Session Table and Troubleshooting Server Iron# rconsole 1 1 ServerIron1/1# show session all 0 Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessinhash, N: sessinnextentry Index Src-IP Dst-IP S-port D-port Age Next Serv Flags ===== ====== ====== ====== ====== === ==== ==== ====== n/a OPT1 H test SLB1 N n/a OPT1 H test SLB1 N 14

15 Health Checks Detailed When Real Server is first defined L2 (ARP) & L3 (PING) Health Checks are Performed When Real Servers are Bound to Virtual Server/Port L4 Health Checks are Performed (Layer 7 If Defined) Subsequent L4/L7 Health Checks Performed if *Keepalive* Enabled Polling Interval 5 seconds * 3 Re-Tries = 15 seconds to Detect Failure Layer 7 Health Checks Support for Many Standard Applications http, DNS, FTP, IMAP4, POP3, LDAP, MMS, NNTP, PNM, RADIUS, RTSP SMTP, SSL (Simple & Complete), Telnet 15

16 Server Iron and Server Farm Packet Walk Through IP= GW= e1 e Server Source IP = e2/1 VIP= DMAC SMAC SIP DIP DPort e1 CMAC e2/4 3 e2/3 4 RS1 IP GW RS2 IP GW e2/1 e RS2 e2/ Real Server #2 IP DMAC SMAC SIP DIP SPort e2/4 RS VIP 5 e2 e2/ CMAC e

17 How to Optimize for Throughput Direct Server Return Explained When Reply Traffic from Server is Large Proportion, Use DSR Return Traffic from Server Bypasses Server Iron Switch Extremely useful for Streaming Media, FTP, Applications ONLY Works when Server Iron and Real Servers in Same L2 Domain Must Configure Loopback Address on Real Servers as the VIP Address Loopback = VIP = Loopback = VIP = Server Iron VIP = Loopback = VIP =

18 How to Create a DSR Configuration? Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server port 80 tcp keepalive 10 2 server real rs url GET /default.html keepalive server real rs url GET /default.html keepalive server virtual vs predictor round-robin dsr bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Virtual IP and Real IP in Same L2 Subnet Add One Line Under Virtual Server > server virtual vs > dsr 18

19 DNS (UDP) Load Balancing Example Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server port dns udp keepalive 10 2 server real rs port dns port dns addr_query port dns keepalive server real rs port dns port dns addr_query port dns keepalive server virtual vs port dns bind dns rs1 dns rs2 dns vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Defining DNS Port and *UDP* Health Profile > server port dns > udp keepalive <interval> <retries> > udp keepalive 10 2 Add L7 DNS Health Check under Real Port > server real rs > Port dns addr_query > Uses DNS L7 Check Against Above Host Address 19

20 Stateless DNS (UDP) Load Balancing Example Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server port dns udp keepalive 10 2 server real rs port dns port dns addr_query port dns keepalive server real rs port dns port dns stateless port dns addr_query port dns keepalive server virtual vs port dns bind dns rs1 dns rs2 dns vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Simply Define Virtual Port for Stateless Load Balancing No Session Table/Flow Information Maintained Packet By Packet Load Balancing is Performed Mostly Useful for Applications that Exchange Two Packets - One Client Request and one Server Response DNS/RADIUS 20

21 Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 21

22 Why Layer 4 vs. Layer 7 Big Differences Layer 4 Operates on TCP Connection Basis Just Like a Call Center Operates on Individual *Call* Basis Relies on IP and TCP Headers to Distribute Traffic Similar to Calling into a Call Center Operation and Directly Getting Connected to the Next Available Operator Layer 4 Implementations are the Simplest ServerIron Designs Layer 7 Operates Based on *User Data* inside Application Message Looks inside Application Messages to Decide where Traffic Goes Similar to Dialing into a Call Center and Being Asked by an Automated System to *Press* a Menu Button Indicating your Need Results in *More Intelligent* Traffic Handling Naturally Requires *More* ServerIron Configuration 22

23 Layer 7 Server Load Balancing Example Problem High Availability and Scalability for Web Servers While Preventing Content Replication on All Servers Content Split Between Servers (or Groups of Servers) Requirements Distribute Traffic to Groups of Servers Based on Content Requested Load Balance within the Same Content Group All Based on Server and Application Health Monitoring Solution ServerIron Layer 7 Load Balancing Configuration Now Let us Build a Configuration for this Scenario 23

24 Back to Call Center Example They do Layer 7 Content Switching When we Call Customer Service Call Center, the Automated System Presents a Menu to Pick Call Operators are Grouped by Specialization Based on Menu Selection, Call is Directed to Appropriate Group Layer 7 Switching on Server Iron is Similar Client Application Must Present Extra Information Prior to Selecting a Server Requests are Directed to Appropriate Group of Servers Based on User Content L4 Load Balance Among Servers with Same Content IP Hdr TCP Hdr HTTP Hdr URL Prefix Text Content (.html) RS1, GRP-id- 1 Client URL Switch IP Network home.foo.com/*.html Server Iron CGI (.bin) Image Content (.gif) RS2, GRP-id- 2 RS3, GRP-id- 3 24

25 Step 1: Identify Incoming Application Data Pattern & Build Switching Policy Identify Application Data by defining Content Switching Rule Look for Application specific details such as- URL Content, http Method, http Version, http header fields (host, cookie), XML Tags > csw-rule <rule-name> <rule-type> <rule-details> > Example: csw-rule r1 url suffix gif Determine Switching Action using Content Switching Policy Switching Actions: Forward, Redirect, Rewrite, Persist > csw-policy <policy-name> match <rule-name> <policy-action> > Example: csw-policy pol1 match r1 forward 1 Server Group ID A Grouping of Servers with Same Content; In this case gif files. 25

26 Step 2: Bind Layer 7 Switching Policy with Virtual Server Apply Intelligent Content Switching Policy to Virtual Server Enable L7 switching for an Application Port > port <port> csw > Example: csw Bind Policy > port <port> csw-policy <policy-name> > Example: csw-policy pol1 Same Policy on Previous Page Forwarding GIF files to Server Group 1 26

27 Step 3: Define Server Group ID for Like Servers with Same Content Use Group ID to club several Servers with Same Content Together Call Operators that answers *Financial* queries fall in one group, and the ones that answer *Technical* queries fall in Another Group > port <port> group-id <id1> <id2> > Example: group-id 1 1 Specify Group ID, Group ID Range - 0 to 1023 > Must be Defined under Each Real Server 27

28 You have an Intelligent Layer 7 Content Switching Configuration module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip csw-rule r1 url suffix "gif" csw-rule r2 url suffix "bin" csw-policy "pol1" match "r1" forward 1 match "r2" forward 2 default forward 3 server real rs group-id 1 1 url GET /default.html keepalive server real rs group-id 2 2 url GET /default.html keepalive Define Content Switching Rule Define Content Switching Policy Define Group-ID server real rs group-id 3 3 url GET /default.html keepalive server virtual vs csw-policy "pol1" csw bind http rs1 http rs2 http rs3 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Cool. My Box is L7 now Bind CSW Policy 28

29 URL Redirection Example Client Request Sent to Alternate URL Page module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip csw-rule "r3" url pattern " csw-policy "pol1" match r3 redirect * " server real rs url GET /default.html keepalive server real rs url GET /default.html keepalive Specify Alternate Redirect URL Define CSW Rule to Identify incoming Pattern server virtual vs csw-policy "pol1" csw It s that Similar bind http rs1 http rs2 http Enable Content Switching & Bind CSW Policy vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway

30 Intelligent Layer 7 Content Switching Guidelines It s Packet Layer 7 It Certainly has Performance Impact About 1/3 rd the Performance of Layer 4 Load Balancing Use it when Performance Impact is a Non-Issue and Layer 7 Inspection is Required for Application to Work Return Traffic MUST Flow through ServerIron NO DSR Possible with Layer 7 30

31 Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 31

32 SYN Attack Protection using ServerIron Example Problem Web Servers have come under TCP SYN Attacks from Hackers Requirements Thwart SYN Attacks & Continue Servicing Legitimate Users Solution ServerIron SYN Attack Protection Configuration Now Let us Build a Configuration for this Scenario 32

33 Step 1: Configure TCP SYN Proxy Feature Enable TCP SYN Proxy Globally Clients Server > Ip tcp syn-proxy <threshold> > Example: ip tcp syn-proxy 10 (A DoS attack threshold specifies the number of SYNs, without corresponding ACKs) Enable TCP SYN Proxy on inbound interface Configurable Threshold Connection Cleared > Ip tcp syn-proxy in > Example: interface ethernet 2/16 ip tcp syn-proxy in That s It Valid Client 33

34 We have a TCP SYN Attack Protection Configuration Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server real rs keepalive server real rs keepalive server virtual vs predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip tcp syn-proxy 10 ip address ip default-gateway interface ethernet 2/16 ip tcp syn-proxy in Enable TCP SYN-Proxy Globally Enabling SYN Proxy on Inbound Interface 34

35 Preventing Flood Attacks using Transaction Rate Limiting Transaction Rate Limiting Limits Number of Transactions from Users Prevents users from monopolizing Server Resources If Transaction Count exceeds specified Threshold then the user would be held down for specified time interval Let s build the configuration 35

36 Step 1: Define Transaction Rate Limiting Policy & Apply Under Virtual Server Define the Rate Limiting Policy > client-trans-rate-limit tcp <trl-name> trl <subnet> <mask> monitor-interval <time in 100ms> conn-rate <transaction-threshold> hold-down-time <time interval> > Example: client-trans-rate-limit tcp trl-1 trl /24 monitor-interval 30 conn-rate 100 hold-down-time 1 Associate Policy with Virtual Server > client-trans-rate-limit <trl policy name> > Example: client-trans-rate-limit trl-1 DONE 36

37 We have Transaction Rate Limit Configuration Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip client-trans-rate-limit tcp trl-1 trl /24 monitor-interval interval 30 conn-rate 100 hold-down-time 1 server real rs keepalive server real rs keepalive server virtual vs client-trans-rate-limit trl-1 bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Applying TRL Policy to VIP TRL Can be Applied Also Under an Interface, But this Example only Shows for VIP TRL Policy Definition 37

38 Maximum Connections Security Maximum Connection limits the Maximum number of Connections to a Real Server or Real Server Port > max-conn <threshold> > Example: max-conn > Port <port> max-conn <threshold> > Example: max-conn Define max-conn Limit of 100,000 per Real Server (All Application Ports) > server real rs max-conn Define max-conn Limit of 5000 per Real Server for HTTP Port > server real rs max-conn

39 Configuring Max-Conn to Protect Servers from Overload Displaying the Configuration will Show: module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server real rs max-conn 5000 keepalive server real rs max-conn 5000 keepalive server virtual vs predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip address ip default-gateway Maximum Connections to HTTP Port on Real Server Set to 5,000 39

40 Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 40

41 Benefits of High Availability Session Table get Synchronized between the two ServerIrons Virtual Application Infrastructure Session Table Server Farm NO Loss of Service when SI Fails Source IP Destination IP Source Port Destination Port Server RS1 RS2 Web Apps Second ServerIron Detects Failure and Services User Flows Rapid Failure Detection Financial Apps Failover is Totally Transparent to User Device Level Redundancy Service Protection Against ServerIron Failures to Provide Even Higher Availability Source IP Destination IP Source Port Destination Port Server RS RS2 Synchronized Session Table ERP Apps 41

42 Active-Hot Standby HA Design MAC=M1 Routers MAC=M2 Active ServerIron VIP= MAC=M4 Standby ServerIron MAC=M5 Dedicated Link for SI Communication MAC=M6 L2 Switch Servers MAC=M7 THE Simplest and Highly Recommended HA Design Now Let us Build a Configuration for this HA Mode 42

43 Step 1: Provide Dedicated Layer 2 Connectivity between two ServerIrons Dedicated Layer 2 Link between the two ServerIrons is MUST Define a separate L2 VLAN on two ServerIrons > vlan <vlan #> by port untagged ethe <m/p> > Example: vlan 999 by port untagged ethernet 2/16 Connect the two ServerIrons through this VLAN Port Disable Spanning Tree on ALL VLANs 43

44 Step 2: Identify Upstream Router Port(s) Designate Upstream Router Port(s) > Server router-ports ethernet <m/p> > Example: server router-ports ethernet 2/1 Upstream Router Port ONLY HA Design that keeps track of upstream router and downstream server ports > SI with higher number of router + server ports becomes Active Router and Server Port Availability is Used to Effect Failover to Ensure the *Most Connected* Server Iron is Active and Processing Traffic 44

45 Step 3: Enable BACKUP Functionality Enable hot-standby BACKUP functionality > server backup ethernet <m/p> <chassis MAC> vlan-id <vlan #> > Example: server backup ethernet 2/1 00e c72 vlan-id 999 Dedicated Link Port Chassis MAC Address Dedicated VLAN The Chassis address used in above command is- > Obtained from show chassis command output on one of the ServerIron > Use the same chassis MAC address for command on other ServerIron Input of MAC Chassis Address Ensures that Same MAC Address is used for VIP Even After Control Fails Over to the Peer Server Iron Device 45

46 We have ServerIron Active-Hot Standby High Availability Configuration module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server source-ip server backup ethe 2/ f233.e400 vlan-id 999 server router-ports ethernet 2/9 server real rs keepalive server real rs keepalive server virtual vs predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port no spanning-tree vlan 999 by port untagged ethe 2/16 no spanning-tree ip address ip default-gateway Enable Backup Functionality Identify Upstream Router Interface Port Disable Spanning Tree for VLAN 1 Define Dedicated VLAN & Port for Session Sync & Disable Spanning Tree When Server Iron is Default Gateway to Real Servers, Don t forget to Configure Source Standby IP This IP Acts as Common Default Gateway IP Across two Devices 46

47 ServerIron SYM-Active HA Design Routers MAC=M1 (VRRP ) MAC=M2 vlan 100 vlan 200 Active ServerIron VIP= MAC=M4 L2 Switches Active ServerIron VIP= MAC=M5 Servers Gateway IP= MAC=M MAC=M MAC=M MAC=M9 BOTH ServerIrons are ACTIVE and Process traffic for same VIP Upstream Routers are Responsible for Distributing Traffic to Both ServerIron Devices on Same VIP This Design is shown with Router Code on ServerIron & uses VRRP definitions on ServerIron and Upstream Routers 47

48 Step 1: Enable SYM-Active Mode and Set SYM Priority for Virtual Server Enable SYM-Active under Virtual Server > Example: sym-active Set SYM Priority for Virtual Server > sym-priority <value> > Example: sym-priority 200 Specify different SYM-Priority on two ServerIrons ServerIron with higher SYM-Priority responds to ARP & ICMP 48

49 Step 2: Enable Session Synchronization Enable Session Table Synchronization for each Application Port > server port <port #> session-sync > Example: server session-sync 49

50 SYM-Active High Availability Configuration Design Changes module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server Enable Session session-sync sync Synchronization server real rs keepalive server real rs keepalive server virtual vs sym-active sym-priority 200 predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port Enable SYM-Active HA Set SYM-Priority NOTE: NO Layer 3 & VRRP details are shown in this Configuration 50

51 Active-Hot Standby vs SYM-Active HA Active-Hot Standby HA The Simplest and Highly Recommended HA Design Second ServerIron remains idle and does not process any SLB traffic SYM-Active HA Return traffic from Real Server CAN hit any SI on its way back You can distribute VIPs (applications) across two ServerIrons by adjusting respective SYM-Priority Dedicated L2 link between two ServerIrons is OPTIONAL MUST have L2 connectivity through other means though 51

52 Thank You Q & A