Netwrking Best Practices Use f a Lad Balancer With Hitachi Cntent Platfrm and Hitachi Cntent Platfrm Anywhere By Hitachi Data Systems August 2015
Cntents Executive Summary... 3 Intrductin... 4 Lad Balancer Cncepts... 5 Hitachi Cntent Platfrm Anywhere... 5 Standard Lad Balancer Setup... 5 Cnfigure DNS... 6 Advanced Lad Balancer Setup... 7 Hitachi Cntent Platfrm... 8 Lad Balance Single (standalne) HCP... 8 Cnfigure DNS... 9 Lad Balance a Pair f Active-Active Replicated HCP Systems... 10 DNS Cnfiguratin... 11 Lad Balancer Availability... 11 Appendix A: zenladbalancer... 12 2
Executive Summary In the wrld f clud and data mbility, there is an expectatin that infrmatin can be accessed anytime, anywhere and frm any device. While this expectancy was riginally driven in the frm f public clud services, enterprise users quickly tk advantage f these services as crprate IT struggled t keep up. As many services are prvided by many clustered entities (servers), each ffering the same service in cnjunctin with its partners, randm but reliable sessin establishment between client devices and the service prviding entities is key. Randmness is required t equally spread the lad acrss all entities, distributing the lad evenly fr the best pssible resurce usage; reliability means that a single failing entity must nt degrade r even circumvent service availability. Up-t-date netwrk design makes use f an active netwrk device, a lad balancer, t prvide the claimed characteristics. This white paper discusses the use f lad balancers fr Hitachi Cntent Platfrm (HCP) and Hitachi Cntent Platfrm Anywhere (HCP Anywhere). 3
Intrductin In cmputing, lad balancing distributes wrklads acrss multiple cmputing resurces, such as cmputers, a cmputer cluster, netwrk links, central prcessing units r disk drives. Lad balancing aims t ptimize resurce use, maximize thrughput, minimize respnse time, and avid verlad f any single resurce (see Figure 1). Using multiple cmpnents with lad balancing instead f a single cmpnent may increase reliability thrugh redundancy. Lad balancing usually invlves dedicated sftware r hardware, such as a multilayer switch r a dmain name system (DNS) server prcess. 1 Figure 1. Generic Scenari HCP and/r HCP Anywhere greatly benefit frm being used thrugh a lad balancer. This white paper discusses these benefits and the cncepts t achieve them. Within this white paper, all examples state t use prt 443. This is true fr data access t HCP thrugh ne f its http(s)/rest-based data access (native, HS3, HSwift) interfaces. Fr Management Cnsle, Search Cnsle r Management API (MAPI) access, replace 443 by 8000, 8888 r 9090. 1 (wikipedia.rg, 2015) 4
Lad Balancer Cncepts A lad balancer, ften called lcal traffic manager (LTM): Is a device that (frm a client s perspective) receives requests thrugh a netwrk interface (custmer netwrk interface), which it then frwards t ne ut f a selectin f back-end servers f equal functinality. This prcess implies that it desn t matter t which server the lad balancer frwards a request, in terms f functinality. Is a device in the data path. Each request must t be prcessed by the lad balancer, making it a single pint f failure, if nt clustered. Has a set f rules it applies t decide t which back-end server t frward a request. Maintains a dictinary f requests in transactin and a dictinary f knwn clients, likely with infrmatin t which backend server it was frwarded recently. Maintains a list f usable back-end servers by cnstantly mnitring their availability. Clsely related t a lad balancer is the cncept f a glbal traffic manager (GTM), which: Is a kind f intelligent DNS server. Is nt in the data path. Has a set f rules it applies t decide which back-end servers IP address t prmte when answering a query. Maintains a list f usable back-end servers by cnstantly mnitring their availability. Answers clients DNS queries with IP addresses accrding t the implemented rules and back-end server availability. Is ften used in multisite envirnments in additin t lcal lad balancers t help keeping traffic lcal as lng as pssible, but allwing fr autmated evasin t ther sites in case n site fails. Hitachi Cntent Platfrm Anywhere HCP Anywhere is a cluster cnsisting f tw servers (ndes) with equal functinality. Clients use https/rest-based API calls t cmmunicate with HCP Anywhere ndes. As each request t the API is atmic and all relevant infrmatin is carried within each single request, it desn t matter t which f the tw ndes a client s request is directed. Standard Lad Balancer Setup Create a server pl (See Figure 2.). Setup a Transmissin Cntrl Prtcl (TCP) based cnfiguratin [dn t need the verhead f an http(s)]. Use bth HCP Anywhere ndes as back-end servers. Create a virtual netwrk interface fr the server pl and assign a static netwrk address t it. Cnfigure the server pl rules t: Be respnsible fr traffic received at prt 443 (https). Distribute traffic rund rbin. (See Figure 3.) Give bth ndes an equal weight and pririty. 5
Make sure that client IP addresses are nt made persistent t a specific back-end nde. Check fr accessibility using TCP at prt 443 (typically built-in). Peridically check fr service availability every few secnds. D an HEAD request t https://hcpaw.dm.lcal:443/prtal, expecting an http cde f 302 as an indicatin that the service is available. Dn t add an authrizatin header t that request: Yu ll want it t redirect yu t the lgin page (indicated by the 302 cde). Figure 2. Example Frm zenladbalancer 2 Cnfiguratin Figure 3. Rund-Rbin Example Frm zenladbalancer Cnfiguratin Cnfigure DNS In additin, it s required t cnfigure DNS t answer with the server pl s virtual netwrk IP address when queried fr HCP Anywhere s Full Qualified Dmain Name (FQDN). Simple additin f a recrd with the respective name and the virtual netwrk IP address is sufficient (see Figure 4). 2 (Sfitel IT Engineering, SL, 2014) 6
Figure 4. DNS Cnfiguratin fr Hitachi Cntent Platfrm Anywhere If HCP Anywhere shall be reachable frm the Internet, external DNS needs t be cnfigured t reslves t that IP, t. Advanced Lad Balancer Setup Using an http(s)-based pl, mre sphisticated cnfiguratins are pssible. Exercise: HCP Anywhere shall be available fr desktp and mbile clients frm the internal netwrk, nly. The nly exceptins t this are public shared links (and flders), which shall be available frm the Internet. Slutin: On the lad balancer, create tw pls: ne fr internal access, the ther fr Internet access. Fr internal access, yu can use the pl shwn in the Standard Lad Balancer Setup descriptin abve. Fr Internet access, create a separate pl: Create a virtual netwrk interface fr the pl and assign a static netwrk address t it. Use https as the pl s base functinality. Cnfigure the pl s rules t: Accept standard HTTP verbs (PUT, GET, HEAD), nly. Select the HTTPS listener. Make sure that client IP addresses are nt made persistent t a specific back-end nde. Allw access t virtual hst <yuranywhere.yurdmain.cm>, nly. Enable URL pattern matching, allwing the fllwing patterns, nly: /mbile/links/public /mbile/links/js /prtal/btstrap /prtal/btstrap/dist/css /prtal/css /prtal/images /prtal/js /u 7
Add yur HCP Anywhere ndes as back-end servers t the pl. Ensure rund rbin fr back-end server selectin. Fr DNS, there are different cnfiguratins fr internal and external name reslutin needed: Cnfigure the internal DNS servers t reslve <yuranywhere.yurdmain.cm> with the internal pl s virtual IP address. Cnfigure the external available DNS servers t reslve <yuranywhere.yurdmain.cm> with the Internet access pl s virtual IP address. Make sure that the said virtual IP addresses are nly available frm the respective netwrk (an external user shuld nt be able t access the internal pl s virtual IP address!). Hitachi Cntent Platfrm HCP is a cluster cnsisting f at least fur and up t 80 ndes, all serving client requests. Unlike HCP Anywhere, it needs t have a certain number f ndes up and running t prvide full functinality. If the number f available ndes falls belw f that, the cluster enters read-nly mde, which a lad balancer has t be cncerned abut. Depending n whether HCP is standalne r is being replicated t a secnd HCP system, the setup f lad balancers will vary. Several scenaris are described here. Lad balancing makes sense fr: All http(s)-based traffic (data, MAPI and management cnsle access). SMTP traffic. Lad Balance Single (standalne) HCP Lad balancing the traffic twards a single HCP is straightfrward (see Figure 5): Create a server pl r farm fr data access. A TCP-based farm is fine [dn t need the verhead f an http(s)-based cnfiguratin]. Cntain all (!) HCP ndes as back-end servers. Create a virtual netwrk interface fr the pl r farm and assign a static netwrk address t it. Cnfigure the pl s rules t: Be respnsible fr traffic received at prt 443 (https). Distribute traffic rund rbin (see Figure 6). Give all ndes an equal weight and pririty. Make sure that client IP addresses are nt made persistent t a specific back-end nde. (This wuld lead a single client ending up using just a single nde, even if making use f multiple cnnectins in parallel. As using multiple cnnectins is a prper way t gain perfrmance r thrughput, this is nt what yu want.) Check fr accessibility using TCP at prt 443 (typically built in). 8
Peridically check fr service availability every few secnds: D an HEAD request t https://<nde IP address>:443/rest, expecting an http cde f 302 as an indicatin that the service is available. Yu need t add an Hst header t the request (hst: namespace.tenant.<hcp_fqdn>), but must nt add an authrizatin header t that request: Yu ll want it t redirect yu t the lgin page (indicated by the 302 cde). Figure 5. Example f Lad Balancing fr HCP Frm zenladbalancer Cnfiguratin. Figure 6. Example f Rund Rbin fr HCP Frm zenladbalancer Cnfiguratin Cnfigure DNS The usual way t cnfigure DNS fr HCP is t set up a stub r >(better) a secndary zne fr HCP s Full Qualified Dmain Name (FQDN, hcp.dm.lcal in the examples). DNS will then respnd with all nde s IP addresses in rund rbin when queried fr Tenants and Namespace. As the lad balancer takes care f using all ndes and needs t be the target fr an applicatin accessing HCP, a different apprach is needed. DNS has t be cnfigured t respnd with the pl s virtual netwrks IP address when queried fr HCPs FQDN. A primary zne is required fr the HCPs FQDN; simply adding a recrd with the respective name and the virtual netwrk s IP address is sufficient. (See Figure 7.) 9
Figure 7. DNS Cnfiguratin fr Hitachi Cntent Platfrm Lad Balance a Pair f Active-Active Replicated HCP Systems Active-active replicatin (als called glbal access technlgy), if prperly cnfigured, allws access t bth HCP systems participating in a replicatin link under the same name. That is, namespace.tenant.hcp1.dm.cm is valid fr bth HCP systems. This allws fr resurce use n bth HCP systems fr active requests (cmpared t ne HCP idling in an activepassive replicatin scenari). It als allws fr switching ver traffic t a single system, instead f initiating a failver in HCP. In certain situatins, using active-active replicatin alng with lad balancers prvides a higher availability fr the verall envirnment. Lad balancing the traffic twards a active-active replicatin-enabled pair f HCPs adds a bit f cmplexity t the lad balancers cnfiguratin (differences t single HCP cnfiguratin in red): Create a cmmn server pl fr data access: A TCP-based farm is fine [dn t need the verhead f an http(s)-based cnfiguratin]. Cntain all (!) ndes f bth (!) HCPs as back-end servers. Create a virtual netwrk interface fr the pl and assign a static netwrk address t it. Cnfigure the pl s rules t: Be respnsible fr traffic received at prt 443 (https). Depending n the situatin, distribute traffic: Rund rbin, if bth HCPs are cmparable gd accessible (bandwidth, latency); Give all ndes an equal weight and pririty. Priritized, if ne HCP has better netwrk cnnectivity than the ther. In this case, yu want t keep traffic lcal as lng as pssible (that is, as lng as the lcal HCP is alive and in read/write mde). Fr each HCP, give all ndes an equal weight and pririty, but differ in pririty between the tw HCPs. Disable all ndes belnging t a single HCP as sn as sn as this HCP enters read-nly mde. This will make sure that applicatins dn t run int failures while nt having write access. Make sure that client IP addresses are nt made persistent t a specific back-end nde. Check fr accessibility using TCP at prt 443 (typically build-in). Peridically check fr service availability every sme secnds: D an HEAD request t https://<nde IP address>:443/rest, expecting an http cde f 302 as an indicatin that the service is available. Yu need t add a hst header t the request (hst: namespace.tenant.<hcp_fqdn>), but must nt add an authrizatin header t that request. Yu ll want it t redirect yu t the lgin page (indicated by the 302 cde). If yu want t make sure that the lad balancer is able t fail ver the entire traffic t the partner HCP in case an HCP enters read-nly mde, yu need t adpt an apprach like this: 10
Create a separate Namespace (ex.: lb.it.<hcp_fqdn>) with minimal capacity (a few 10GB will d). DPL1, having the prtcl in questin enabled, alng with versining, set t ne day. (This will allw the lad balancer t write that file again and again while nt ver cnsuming strage in HCP.) Create a lcal user with read/write access rights t that Namespace. D a PUT request t https://<nde IP address>:443/rest/lbtest.txt, sending a minimal file (a few bytes), expecting an http cde f 201 as an indicatin that the service is available. Yu need t add a hst header t the request (hst: lb.it.<hcp_fqdn>) and an authrizatin header t that request. Read the Using a Namespace manual n hw t create thse headers. Yu ll als have t add a rule t the lad balancer s pl that recgnizes that a failver is needed in case the ndes enter read-nly mde. DNS Cnfiguratin This cnfiguratin fllws the same apprach as that described in Lad Balancing fr Single (standalne) HCP. Lad Balancer Availability A single lad balancer in the data path t either HCP r HCP Anywhere is a single pint f failure. T prevent an instance in which HCP r HCP Anywhere becme unavailable by a defective lad balancer, the lad balancers are typically deplyed as clustered pairs. Cnfiguratin depends n vendr and mdel, but always leads t bth f them sharing the pls virtual IP address. Anther deplyment methd is t use a glbal traffic manager t distribute traffic acrss all lad balancers (lcal traffic managers) in charge fr a pl. In this case, the GTM will mnitr the availability f the LTMs and rutes traffic by answering DNS queries accrdingly. 11
Appendix A: zenladbalancer zenladbalancer 3 is an pen-surce lad balancer, available as Cmmunity and Enterprise Editin. The Cmmunity Editin can be dwnladed as an ISO image, which is easily installable n a virtual machine running n any hypervisr. Please see dwnlad and dcumentatin sectin n the zenladbalancers website. While cnfiguratin f zenladbalancer is mainly dne thrugh the prvided webgui, sme tasks can becme very annying due t the need t enter the same infrmatin repeatedly. Knwing abut the internal structure, it is pssible t cpy already existing cnfiguratins and adpt them t different needs. All cnfiguratin files are lcated in the /usr/lcal/zenladbalancer/cnfig flder: glbal.cnf the base cnfiguratin file. <farm_name>_pen.cfg cnfiguratin fr TCP-based farms. <farm_name>_pund.cfg cnfiguratin fr HTTP(S)-based farms. <farm_name>_err???.html custm errr messages per farm. if_eth?:?_cnf netwrk interface cnfiguratin files. zlb-start, zlb-stp custm scripts that will be run after zenladbalancer has started / befre it ges dwn Lg files can be fund in /usr/lcal/zenladbalancer/lgs. 3 www.zenladbalancer.cm 12
Crprate Headquarters 2845 Lafayette Street Santa Clara, CA 95050-2639 USA www.hds.cm cmmunity.hds.cm Reginal Cntact Infrmatin Americas: 866 374 5822 r inf@hds.cm Eurpe, Middle East and Africa: +44 (0) 1753 618000 r inf.emea@hds.cm Asia Pacific: +852 3189 7900 r hds.marketing.apac@hds.cm HITACHI is a trademark r registered trademark f Hitachi, Ltd Micrsft is a trademark r registered trademark f Micrsft Crpratin. All ther trademarks, service marks, and cmpany names are prperties f their respective wners. WP-538-A HDS August 2015