Serv-U Distributed Architecture Guide Hrizntal Scaling and Applicatin Tiering fr High Availability, Security, and Perfrmance Serv-U Distributed Architecture Guide v15.1.2.0 Page 1 f 20
Intrductin Serv-U is a high-perfrmance secure file transfer server fr Windws and Linux. It supprts FTP, FTPS (SSL/TLS), SFTP (SSH), HTTP, and HTTPS cnnectins, and includes ptimized interfaces fr web brwsers and mbile devices (e.g., ipad, iphne, BlackBerry, Andrid, Micrsft Windws Mbile, and Kindle Fire). T supprt stringent redundancy, security, and perfrmance requirements Serv-U supprts bth multitier and high availability architectures. This dcument describes Serv-U s supprt fr these distributed architectures and their relative advantages and disadvantages. N Data in DMZ fr Managed File Transfer A multi-tier Serv-U / Serv-U Gateway deplyment allws yu t meet a cmmn managed file transfer requirement: never stre data at rest in a DMZ. Serv-U Gateway safely prxies incming cnnectins frm the Internet t yur Serv-U server withut pening any cnnectins frm the Internet r yur DMZ segment int yur trusted netwrk. Imprtant: The File Sharing mdule f Serv-U currently des nt supprt High Availability envirnments. High Availability is designed fr file transfers nly. High Availability thrugh Hrizntal Scaling Bth the cre Serv-U server and Serv-U Gateway can be deplyed in N+1 cnfiguratins t achieve high availability thrugh hrizntal scaling. This allws yu t avid single pints f failure r scale up t meet yur needs. Serv-U Distributed Architecture Guide v15.1.2.0 Page 2 f 20
Serv-U Distributed Architecture Guide v15.1.2.0 Page 3 f 20
Table f Cntents Intrductin... 2 N Data in DMZ fr Managed File Transfer... 2 High Availability thrugh Hrizntal Scaling... 2 Hardware Requirements... 5 Basic Deplyment... 6 Basic Multi-Tier (MFT) Deplyment... 9 Basic High-Availability (N+1) Deplyment... 11 Highly-Available Multi-Tier (MFT) Deplyment... 13 Gateway Cmmunicatin Details... 17 Additinal References... 19 Ntices... 20 Serv-U Distributed Architecture Guide v15.1.2.0 Page 4 f 20
Hardware Requirements This sectin cntains the minimum hardware requirements that need t be met, s that a given number f simultaneus transfers can be handled thrugh the different prtcls. The prvided data refer t single-instance Serv-U installatins. Fr example, a single-instance installatin can handle 500 simultaneus transfers thrugh FTP with the given hardware. If yu expect t have 1000 simultaneus transfers, it is recmmended that yu install 2 Serv-U instances, each f them meeting the requirements needed t handle 500 simultaneus transfers. If the lad is higher than expected fr a given cnfiguratin, Serv-U remains functinal, but the transfer rates will be diminished, and the user interface becmes less respnsive. Number f simultaneus transfers per prtcl FTP (uncmpressed **), HTTP 10 512 MB RAM 7200 RPM HDD 2 cre CPU * 25 1 GB RAM 7200 RPM HDD 2 cre CPU * 50 2 GB RAM 10000 RPM HDD 4 cre CPU * 100 4 GB RAM 2x 10000 RPM HDD (RAID) 4 cre CPU * 200 4+ GB RAM SSD HDD r 2x 10000 RPM HDD 4+ cre CPU * 500 8+ GB RAM SSD HDD r 2x 15000 HDD (RAID) 8+ cre CPU * 1000 Multiple instances f Serv-U (2x) Encrypted (HTTPS, SFTP) 1 GB RAM 7200 RPM HDD 4 cre CPU * 2 GB RAM 7200 RPM HDD 4 cre CPU * 4 GB RAM 10000 RPM HDD 4+ cre CPU * Multiple instances f Serv-U (2x) Multiple instances f Serv-U (4x) Please cntact SlarWinds t define the requirements fr yur envirnment. Please cntact SlarWinds t define the requirements fr yur envirnment. * Using CPU with higher perfrmance per cre has significantly better impact n perfrmance than increasing the number f CPU cres, therefre it is recmmended that yu use CPUs with higher clck rates. Serv-U Distributed Architecture Guide v15.1.2.0 Page 5 f 20
** These recmmendatin are valid fr FTP transfers with data cmpressin disabled. If data cmpressin is enabled, CPU requirements are ntably higher. Fr best results, it is recmmended t use CPU with as high perfrmance per cre as pssible. Scalability Tips and Best Practices: One Serv-U Gateway shuld be capable f gracefully handling at least 2 Serv-U server instances. Opening a list f users in the Management Cnsle is a highly CPU intensive peratin. Fr better perfrmance, it is recmmended that yu divide users int cllectins, and avid managing users' lists during heavy lads. It is als recmmended that during heavy lads, yu avid pening and navigating in the Management Cnsle, especially n pages that display lgs which are refreshed at shrt intervals. Fr best perfrmance, use a HDD r SSD with high IOPS rate. A high IOPS rate increases the perfrmance in the case f 50+ simultaneus transfers. The recmmended netwrk speed is 1000+ Mbit/s fr all types f file transfers. Basic Deplyment When Serv-U is deplyed as a standalne server it is typically prtected frm the Internet by a single firewall. It may be cnnected t remte strage r remte authenticatin surces. All editins f Serv-U may be deplyed in this architecture, but nly Serv-U MFT Server may leverage external authenticatin surces. Serv-U Distributed Architecture Guide v15.1.2.0 Page 6 f 20
Firewall Cnfiguratin: The primary firewall supprts FTP, FTPS (SSL/TLS), SFTP (SSH), HTTP, and/r HTTPS inbund cnnectins frm the Internet int Serv-U. This firewall may als be cnfigured t allw utbund cnnectins fr supprt FTP/S active mde data cnnectins, r may be FTP aware enugh t pen FTP data channels dynamically. Variatins: If Serv-U accesses remte strage (fr example, NAS r file shares), then Serv-U must be able t make a CIFS (Windws netwrking) cnnectin t thse resurces. If Serv-U accesses an ODBC-cmpliant database fr remte authenticatin, then Serv-U must be able t make a database-apprpriate cnnectin t that database. Fr example, SQL Server cnnectins are ften made ver TCP prt 1433. If Serv-U accesses Active Directry ( AD ) fr remte authenticatin, then yur Serv-U server must be part f the AD dmain and must be n the same netwrk segment. Serv-U Distributed Architecture Guide v15.1.2.0 Page 7 f 20
Advantages: Easiest cnfiguratin t set up. (This cnfiguratin is recmmended during functinal evaluatin f Serv-U sftware.) Disadvantages: N active redundancy means the Serv-U server is a single pint f failure. Direct cnnectins frm Serv-U t internal strage, internal databases, r Active Directry dmain cntrllers are nt permitted by many security plicies. Serv-U Distributed Architecture Guide v15.1.2.0 Page 8 f 20
Basic Multi-Tier (MFT) Deplyment The Serv-U Gateway allws yu t deply Serv-U in a multi-tier architecture that meets r exceeds mst managed file transfer ( MFT ) security requirements. This architecture allws yu t: Terminate all incming transfer cnnectins n a hardened server lcated in yur DMZ segment Ensure n data is ever stred in yur DMZ segment Avid pening any inbund cnnectins frm yur DMZ segment t the internal netwrk Serv-U FTP Server* and Serv-U MFT Server may be deplyed in this architecture, but Serv-U MFT Server shuld be used if yu supprt SFTP (SSH) r HTTPS transfers r plan t leverage external authenticatin surces. * Serv-U FTP Server des nt supprt SFTP r HTTPS. Firewall Cnfiguratin: Serv-U Distributed Architecture Guide v15.1.2.0 Page 9 f 20
The firewall between the Internet and the DMZ segment supprts FTP, FTPS (SSL/TLS), SFTP (SSH), HTTP, and/r HTTPS inbund cnnectins frm the Internet int Serv-U. This firewall may als be cnfigured t allw utbund cnnectins t supprt FTP/S active mde data cnnectins, r may be FTP aware enugh t pen FTP data channels dynamically. The firewall between the DMZ segment and the internal netwrk nly needs t allw utbund cnnectins frm Serv-U t Serv-U Gateway ver TCP prt 1180. Variatins: If Serv-U accesses remte strage (fr example, NAS r file shares), then Serv-U must be able t make a CIFS (Windws netwrking) cnnectin t thse resurces. If Serv-U accesses an ODBC-cmpliant database fr remte authenticatin, then Serv-U must be able t make a database-apprpriate cnnectin t that database. Fr example, SQL Server cnnectins are ften made ver TCP prt 1433. If Serv-U accesses Active Directry ( AD ) fr remte authenticatin, then yur Serv-U server must be part f the AD dmain and must be n the same netwrk segment. The tw firewalls represented in the diagram are really ften tw legs f a single firewall cntrlling access between multiple segments. Serv-U Gateway and Serv-U may be deplyed n different perating systems, fr example, yur Internet-facing Serv-U Gateway can be deplyed n Linux even if yu have deplyed yur Serv-U server n Windws. Advantages: Still easy t set up. (Install Serv-U Gateway, define Serv-U Gateway, define Serv-U listeners, test, and g.) Fully satisfies the MFT requirement that n data at rest exists in the DMZ. Satisfies mst security plicy requirements by ensuring that direct cnnectins t internal strage, internal databases, r Active Directry dmain cntrllers are nly made between cmputers n yur trusted internal netwrk. N CIFS, AD, r DB cnnectins are ever made acrss a firewall. Disadvantages: N active redundancy means the Serv-U server and Serv-U Gateway are single pints f failure. Serv-U Distributed Architecture Guide v15.1.2.0 Page 10 f 20
Basic High-Availability (N+1) Deplyment Serv-U can be deplyed as a web farm f applicatin servers t prvide highly available ( HA ) services thrugh hrizntal scaling (a.k.a. N+1 ). Serv-U MFT Server is the nly Serv-U editin that supprt HA deplyments because Serv-U s HA cnfiguratin requires the use f external authenticatin surces. Up t five Serv-U servers are currently allwed in this cnfiguratin. Firewall Cnfiguratin: The primary firewall supprts FTP, FTPS (SSL/TLS), SFTP (SSH), HTTP, and/r HTTPS inbund cnnectins frm the Internet int Serv-U. This firewall may als be cnfigured t allw utbund cnnectins t supprt FTP/S active mde data cnnectins, r may be FTP aware enugh t pen FTP data channels dynamically. Lad Balancer: Serv-U Distributed Architecture Guide v15.1.2.0 Page 11 f 20
A netwrk lad balancer must be used t distribute incming cnnectins t each Serv-U server. Lad balancers shuld be cnfigured t preserve riginal IP addresses if yu want t use Serv-U s IP lckut prtectin. Lad balancers shuld als use sticky sessins that lck all incming cnnectins frm a particular IP address t a specific Serv-U server t allw FTP and FTPS cnnectins t wrk prperly. Remte Strage: All user hme flders, virtual flders and ther Serv-U flders must be cnfigured t use remte strage (fr example, NAS r file shares) rather than lcal hard drives. Serv-U must be able t make a CIFS (Windws netwrking) cnnectin t thse resurces. Remte Authenticatin: All Serv-U dmains must use remte authenticatin prvided by an ODBC-cmpliant database r Micrsft Active Directry (AD). If Serv-U accesses an ODBC-cmpliant database fr remte authenticatin, then Serv-U must be able t make a database-apprpriate cnnectin t that database. Fr example, SQL Server cnnectins are ften made ver TCP prt 1433. If Serv-U accesses Active Directry ( AD ) fr remte authenticatin, then yur Serv-U server must be part f the AD dmain and must be n the same netwrk segment. Variatins: On Windws Server the built-in Windws Netwrk Lad Balancer service can be used instead f a physical lad balancer. Advantages: Active redundancy means that yur Serv-U applicatin servers are nt single pints f failure. Disadvantages: Mre difficult t set up than single-nde systems. Yu must install Serv-U n each applicatin server and pint t the same shared resurces. Direct cnnectins frm Serv-U t internal strage, internal databases, r Active Directry dmain cntrllers are nt permitted by many security plicies. Live user statistics may be unreliable fr individual users wh sign n t multiple servers simultaneusly. This can be partially mitigated fr end user statistics nt grup statistics fr end users wh sign n frm a single IP at a time via sticky sessins n yur lad balancer. Serv-U Distributed Architecture Guide v15.1.2.0 Page 12 f 20
Highly-Available Multi-Tier (MFT) Deplyment Serv-U can be deplyed as a web farm f applicatin servers t prvide highly available ( HA ) services thrugh hrizntal scaling (a.k.a. N+1 ). It can als be deplyed in a multi-tier architecture that meets r exceeds mst managed file transfer ( MFT ) security requirements. Tgether, this sphisticated architecture allws yu t: terminate all incming transfer cnnectins n a hardened server lcated in yur DMZ segment ensure n data is ever stred in yur DMZ segment avid pening any inbund cnnectins frm yur DMZ segment t the internal netwrk avid single pints f failure scale up r dwn t meet actual demand Serv-U MFT Server is the nly Serv-U editin that supprts HA multi-tier deplyments because Serv-U s HA cnfiguratin requires the use f external authenticatin surces. Up t five Serv-U servers and three Serv-U Gateways are currently allwed in this cnfiguratin. Serv-U Distributed Architecture Guide v15.1.2.0 Page 13 f 20
Firewall Cnfiguratin: The primary firewall supprts FTP, FTPS (SSL/TLS), SFTP (SSH), HTTP, and/r HTTPS inbund cnnectins frm the Internet int Serv-U. This firewall can als be cnfigured t allw utbund cnnectins t supprt FTP/S active mde data cnnectins, r may be FTP aware enugh t pen FTP data channels dynamically. The firewall between the DMZ segment and the internal netwrk nly needs t allw utbund cnnectins frm each f the Serv-U servers t each f the Serv-U Gateways ver TCP prt 1180. Lad Balancer: A netwrk lad balancer must be used t distribute incming cnnectins t each Serv-U Gateway. Lad balancers shuld be cnfigured t preserve riginal IP addresses if yu want t use Serv-U s IP lckut prtectin. Lad balancers shuld als use sticky sessins that lck all incming cnnectins frm a particular IP address t a specific Serv-U server t allw FTP and FTPS cnnectins t wrk prperly. Serv-U Distributed Architecture Guide v15.1.2.0 Page 14 f 20
N lad balancer is required between the Serv-U Gateway tier and the Serv-U server tier. Remte Strage: All user hme flders, virtual flders and ther Serv-U flders must be cnfigured t use remte strage (fr example, NAS r file shares) rather than lcal hard drives. Each Serv-U server must be able t make a CIFS (Windws netwrking) cnnectin t thse resurces. Remte Authenticatin: All Serv-U dmains must use remte authenticatin prvided by an ODBC-cmpliant database r Micrsft Active Directry (AD). If Serv-U accesses an ODBC-cmpliant database fr remte authenticatin, then each Serv-U server must be able t make a database-apprpriate cnnectin t that database. Fr example, SQL Server cnnectins are ften made ver TCP prt 1433. If Serv-U accesses Active Directry ( AD ) fr remte authenticatin, then yur Serv-U server must be part f the AD dmain and must be n the same netwrk segment. Variatins: On Windws Server the built-in Windws Netwrk Lad Balancer service can be used instead f a physical lad balancer t prvide lad balancing services t Serv-U Gateway. The tw firewalls represented in the diagram are smetimes tw legs f a single firewall cntrlling access between multiple segments. Serv-U Gateway and Serv-U may be deplyed n different perating systems. Fr example, yur Internet-facing Serv-U Gateway can be deplyed n Linux even if yu have deplyed yur Serv-U server n Windws. Hwever, all Serv-U Gateways shuld use the same perating system and all Serv-U Servers shuld use the same perating system whenever pssible. Advantages: Active redundancy means that yur Serv-U applicatin servers are nt single pints f failure. Fully satisfies the MFT requirement that n data at rest exists in the DMZ. Satisfies mst security plicy requirements by ensuring that direct cnnectins t internal strage, internal databases, r Active Directry dmain cntrllers are nly made between cmputers n yur trusted internal netwrk. N CIFS, AD, r DB cnnectins are ever made acrss a firewall. Disadvantages: Serv-U Distributed Architecture Guide v15.1.2.0 Page 15 f 20
Mre difficult t set up than single-nde r single-tier systems. Yu must install Serv-U n each applicatin server and pint t the same shared resurces. Yu must als cnfigure a lad balancer and cnfigure Serv-U Gateways n bth Serv-U servers. Live user statistics may be unreliable fr individual users wh sign n t multiple servers simultaneusly. This can be partially mitigated fr end users wh sign n frm a single IP at a time by using sticky sessins n yur lad balancer. Serv-U Distributed Architecture Guide v15.1.2.0 Page 16 f 20
Gateway Cmmunicatin Details Serv-U Gateway is able t act as a secure reverse prxy by aviding direct cnnectins frm the Internet r the DMZ int the internal netwrk. Behind the scenes, all inbund cnnectins are served by Serv-U Gateway by tying them t utbund cnnectins frm the internally-based Serv-U server. This allws Serv-U Gateway t perfrm its duty withut ever making an inbund cnnectin frm the DMZ segment t the trusted netwrk. Assumptins: The firewall guarding access frm the Internet t the DMZ segment is cnfigured t allw standard file transfer services (fr example, FTP/S, SFTP via SSH, HTTPS, and s n) t the Serv-U Gateway. The firewall guarding access frm the DMZ segment t the trusted internal netwrk des nt permit any cnnectins frm the DMZ t the internal netwrk. Serv-U Gateway is pwered up and listening fr cnnectins in the DMZ segment. Serv-U Distributed Architecture Guide v15.1.2.0 Page 17 f 20
Serv-U is installed in the trusted internal netwrk. Cmmunicatin Walkthrugh: 1. When a Serv-U server starts up, it tries t cnnect t all its cnfigured Serv-U Gateways. As it cnnects t each ne, Serv-U prvides specific instructins t each Serv-U Gateway abut the prtcls, IP addresses, and prts it shuld use t serve cnnectins frm the Internet. The cnnectin Serv-U uses t prvide this infrmatin is pened and reestablished as necessary s Serv-U Gateway can send messages back t Serv-U. This cnnectin can be thught f as the gateway cntrl channel r GCC. 2. When a file transfer client (fr example, web brwser, ipad, r FTP client) pens a cnnectin t the Serv-U Gateway, the Serv-U Gateway will ask abut the cnnectin ver the existing GCC. Serv-U perfrms any necessary IP checks and authenticatin against its wn database r internal resurces. 3. If Serv-U apprves the incming cnnectin, Serv-U makes a new utbund cnnectin frm Serv-U t the Serv-U Gateway. This secnd cnnectin can be thught f as the gateway data channel r GDC. If Serv-U denies the incming cnnectin Serv-U tells the Serv-U Gateway t deny the cnnectin via the GCC and the Serv-U Gateway terminates the requesting client s cnnectin. 4. Serv-U Gateway stitches the riginal client cnnectin and the GCD created fr the apprved cnnectin tgether. Frm that pint frward data transfer ccurs between the client and Serv- U until either side terminates the sessin. Security: Use f prtcls that encrypt data in transit (fr example, FTPS, SFTP ver SSH and HTTPS) is supprted and encuraged when clients cnnect t Serv-U Gateway. The cmmunicatin channels between Serv-U and Serv-U Gateway always encrypt all traffic between thse tw systems, regardless f the prtcl the client used t cnnect. This prvides end-t-end secure transprt when clients use a secure prtcl. N data r authenticatin infrmatin is ever stred at rest in the DMZ. Serv-U Distributed Architecture Guide v15.1.2.0 Page 18 f 20
Additinal References The Serv-U Administratr Guide describes hw t set up dmains, grups, user, and flders t supprt a Serv-U HA deplyment. The fllwing sectins are particularly pertinent: Mapping hme flders and virtual flders t Windws Shares Virtual Paths sectin Physical Path subsectin User Infrmatin sectin Hme Directry subsectin Directry Access Rules sectin Access as Windws Users subsectin Using a cmmn share t handle SSH keys, SSL certificates, server welcme message, FTP message files, event cmmand executables, and lg files User Infrmatin sectin, SSH Public Key Path subsectin Encryptin sectin, Cnfiguring SSL fr FTPS and HTTPS subsectin Encryptin sectin, SFTP (Secure File Transfer ver SSH2) subsectin FTP Settings sectin, Server Welcme Message subsectin FTP Settings sectin, Message Files subsectin Serv-U Events sectin, Execute Cmmand Actins subsectin Cnfiguring Dmain Lgs sectin, Lg File Path subsectin Using external authenticatin Dmain Settings t set database-based r Active Directry authenticatin Serv-U Database Integratin Guide fr database-based authenticatin Serv-U Windws Grups sectin fr Active Directry authenticatin The Serv-U Database Integratin Guide cntains detailed infrmatin and instructins t set up an authenticatin database in supprt f Serv-U web farms. Supprted databases include SQL Server, Oracle Database, MySQL, PstGres, and several ther ODBC-cmpliant relatinal databases. Serv-U Distributed Architecture Guide v15.1.2.0 Page 19 f 20
Ntices This dcument is prvided fr use with the setup and maintenance f the Serv-U File Server. This manual is prvided "AS IS" and withut warranties as t the accuracy f the infrmatin r any ther warranties whether expressed r implied. Because f the varius hardware and sftware envirnments int which Serv-U may be put, NO WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE IS OFFERED. Gd data prcessing practice dictates that any new prgram shuld be thrughly tested by the user with nn-critical data befre relying n it. The user must assume the entire risk f using the prgram. ANY LIABILITY OF THE SELLER WILL BE LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR, AT THE SELLER'S DISCRETION, A REFUND OF PURCHASE PRICE. Serv-U is a registered trademark f SlarWinds, Inc. Cntact Infrmatin SlarWinds, Inc. Phne: +1 (855) 498-4154 Office Hurs: 9 AM 5 PM Central Time, United States Sales Supprt: http://www.serv-u.cm/cntact.asp Technical Supprt: http://www.serv-u.cm/emailsupprt.asp?prd=rs&prduct=rs&emailtype=tech Knwledge Base: http://www.serv-u.cm/kb/ Crprate Website: http://www.serv-u.cm/ Serv-U Distributed Architecture Guide v15.1.2.0 Page 20 f 20