Planning Your Serv-U Gateway Deployment - KB Article #2077Related Articles -- 2103, 2076, 2075
This article provides a project template that allows you to select the right Serv-U architecture and coordinate with related IT teams to deploy Serv-U Gateway into production.
General Planning Process
Start by identifying which architecture fits your needs and how much it will cost to obtain.
1) Download and review the Serv-U Distributed Architecture Guide.
2) Select the architecture that best fits your needs: high-availability, defense in depth, or both.
|High Availability||Defense in Depth||Both|
3) Print a copy of the section of the Serv-U Distributed Architecture Guide that describes your architecture.
You can mark the diagram from this section up with ownership information, IP addresses and other details as you move through this process.
4) Identify the necessary licenses to fulfill this architecture and budget the purchase.
You may be surprised by how little our distributed Serv-U solutions cost. Our usual competitors charge a great deal more for the same or worse functionality. Contact us for a quote or need help deciding which licenses you need.
Distributed systems often require coordination across multiple IT teams, and a distributed Serv-U system is no exception.
1) Find out who owns your:
- Firewalls - This team will need to open a port (TCP 1180) from Serv-U to Serv-U Gateway and will either need to open the same ports to Serv-U Gateway that they did for Serv-U or switch Serv-U's existing rules over to Serv-U Gateway.
- Load Balancer - If you deploying a web farm architecture, this team will need to set up "sticky" sessions for your FTP and FTPS connections (same external IP uses same internal node for all connections) and "round robin" connections for SFTP, HTTP and HTTPS connections.
- Shared Storage ("NAS") - If you are deploying a web farm or are using Serv-U to provide secure or mobile access to shared storage you must coordinate with this team.
- Database - If you are using a database to provide Serv-U credentials you must coordinate with this team.
- Active Directory - If you are using a Microsoft Active Directory to provide Serv-U credentials you must coordinate with this team.
- Web Portal - If you are have integrated Serv-U into your existing web portal(s) you must coordinate with this team.
2) Send an email to all teams involved to announce the project.
Include a copy of the diagram that matches your selected architecture, a link to the Serv-U Distributed Architecture Guide and a brief description of the scope of your project. You may want to start with the following letter and adjust to taste.
We are hoping to [re]deploy Serv-U with Serv-U Gateway, its reverse proxy component, to provide even more secure and reliable file transfers within the next  days. Since this is a public-facing application that ties into internal resources we will need your help.
We have decided on a [TYPE OF DEPLOYMENT] deployment and have enclosed an architectural diagram that shows the components involved. More details are on this architecture are available from the online Serv-U Distributed Architecture Guide.
We expect we will need help in the following areas:
- Firewall: Open TCP port  from Serv-U to Serv-U Gateway. Switch incoming ports now pointing directly to Serv-U to Serv-U Gateway instead. [Or list the usual Serv-U ports if this is a new deployment.]
- Load Balancer: Set up "sticky" sessions for FTP and FTPS connections (same external IP uses same internal node for all connections) and "round robin" connections for SFTP, HTTP and HTTPS connections. [Only necessary with web farm deployments.]
- Shared Storage ("NAS"): Provide space for Serv-U specific storage (e.g., folders for trading partners) and access to existing shared storage for employees and contractors who want web, mobile, or FTP access to their files. [Edit as necessary.]
- Database Set up a new database for Serv-U to store authentication information or tie into an existing database so Serv-U can share authentication. [Only necessary if Serv-U is using database authentication.]
- Active Directory - Provide access to AD from Serv-U (not the Serv-U Gateway in the DMZ). [Only necessary if Serv-U is using Active Directory authentication.]
I have set up a [meeting or concall] at [TIME] on [DATE] to discuss. Please send the appropriate representative.
The first purpose of your meetings will be to identify the exact scope of your project and the time frame in which it can be achieved. Next, a project plan should be developed to coordinate resources and schedule. After that your meetings should switch to project status updates governed by the project plan.
Typical Agenda for Kickoff Meeting
- Role of Serv-U (e.g., secure file exchange, web/mobile access to files, etc.)
- Need for Change (e.g., critical application, security, etc.)
- Solution (Serv-U's new architecture)
- Desired Timeframe (e.g., "in production in 90 days")
- Coordinating Teams (also good time to do introductions)
- Scoping Discussion
- Serv-U server (e.g., direct access to internal resources, connects to Serv-U Gateway)
- Serv-U Gateway (e.g., deployed in DMZ, receives incoming connections from the Internet)
- Internet/DMZ Firewall (e.g., allow file transfer protocols to connect to Serv-U Gateway)
- DMZ/Internal Firewall (e.g., allow TCP port 1180 to connect to Serv-U Gateway)
- Load Balancer (IF NEEDED)
- Shared Storage (IF NEEDED)
- Database (IF NEEDED)
- Active Directory (IF NEEDED)
- Scoping Summary
- Does each team understand its role?
- What is ballpark time/materials estimate for each role? What is lead time before each team could begin?
- Are there significant roles without an owner? (i.e., Should we have invited someone else?)
- Next Steps
- Proof of concept?
- Specify machines, IP addresses, firewall rules, routes, load balancer policies, database access, shared storage access and other resources (e.g., a project manager?) needed to complete this project
- File necessary tickets, Serv-U purchase orders, and other paperwork needed to advance project
- Schedule next meeting
Use a follow-up meeting or two to ensure all work has an owner and a time estimate. Once the scope of the assignment is known, schedule this work in a project plan and work with your identified teams to execute the plan.
Typical Project Schedule
The following schedule assumes that you have already selected an architecture and are starting with the kickoff meeting described above.
- Day 1: Kickoff Meeting
- Day 8: Kickoff Follow-up Meeting #1
- Day 15: Kickoff Follow-up Meeting #2
- Day 15: DELIVERABLE: Project Scope
- Day 15: DELIVERABLE: Target Deployment Date
- Day 15-30: Project manager works with identified project teams to build a schedule that arrives at or near the target deployment date.
- Day 30: DELIVERABLE: Project Plan
- Day 30: DELIVERABLE: Scheduled Outage for Cut-Over
- Day 31: Serv-U licenses are purchased.
- Day 31-45: Infrastructure (hardware, virtual machines, operating systems, firewalls, routers, load balancers, database access and shared storage access) is provisioned
- Day 45: DELIVERABLE: Required Infrastructure
- Day 46: Serv-U applications are installed and configured.
- Day 46-60: Load tests and other testing is conducted against Serv-U components before being swung into production.
- Day 61: Swing Serv-U into production during scheduled downtime
- Day 61: DELIVERABLE: Serv-U and Serv-U Gateway in Production
Serv-U Gateway is built so you can safely attach a new Gateway to an existing production system without interrupting any existing services. However, a planned outage is still required to switch incoming traffic from an existing Serv-U server to your new Serv-U Gateway. This section explains where this outage fits in the context of a cut-over to production.
1) Install Serv-U Gateway, configure Gateway, set up Gateway Listeners and test your Listeners several days BEFORE you swing into production.
Follow the appropriate set of directions for your operating system.
2) Double-check the following BEFORE you swing Serv-U Gateway into production.
- The new internal IP address of your Serv-U server. If you are using IP access controls on your Active Directory, database and/or shared storage resources, this new IP address should be authorized on those resources before cut-over.
- The existence of an internal-to-DMZ firewall rule that permits Serv-U to connect to Serv-U Gateway.
- Physical rack space, cabling, router ports and personnel to switch Serv-U out of the DMZ and into the internal network. (If the existing Serv-U server will be moved; otherwise, plan to perform a complete backup/restore to a new Serv-U server on the internal network.)
3) If possible, turn on external-to-DMZ firewall rules to Serv-U Gateway BEFORE cut-over. This will allow you to do some external-to-Gateway testing with file transfer clients before cut-over.
4) Perform cut-over during a 2 to 4 hour window.
Prepare an ordered checklist for this. A starter checklist is provided below.
- Send notification of outage start.
- Disable firewall rules to existing Serv-U server.
- Shut down existing Serv-U server.
- Move existing Serv-U server to internal network OR perform final backup/restore to new Serv-U server on internal network.
- Start Serv-U Gateway (if offline).
- Start (moved or new) Serv-U server.
- Ensure Serv-U can connect to Serv-U Gateway.
- Ensure configured Listeners are active on Serv-U Gateway.
- Enable firewall rules to Serv-U Gateway.
- Test Serv-U Gateway through the External/DMZ firewall using file transfer clients such as FTP Voyager.
- Send notification of outage end.
If all goes smoothly, this procedure can be performed in fifteen minutes. However, a missed firewall rule or IP address change can take an hour or more, so please allow enough time to recover from missteps during your planned outage.
Additional assistance is available from our Technical Support Team.