This is a question for someone with a lot of experience networking application servers or for a network engineer who worked intimately to support a team or someone who did.
If I were going to roll out a new suite of applications (JD Edwards EnterpriseOne , for example) , what considerations would I have to make with regard to network architecture and connectivity?
For example, creating a dual-homed server architecture for NIC/switch-port redundancy. Or creating a management vlan, separate from the data vlan, and using a separate NIC for that. Or perhaps placing an application server that has to constantly sieze information from an SQL database server on the same vlan/subnet to avoid layer 3 switching (routing) between hosts on different vlans. Or maybe placing the production servers and dev servers in separate vlans, etc.
The reason I am asking is that I am going to have to help an applications support group make network architecture decisions when they roll out the new suite of applications and associated servers.
From a networking perspective, all I have to do is configure an L2 server farm access switch and trunk the vlans up to a distribution layer. But I want to help them make the decision regarding how many vlans to create and how to subnet them, etc.
I haven't worked with EnterpriseOne but i have been heavily involved with an Oracle ERP implementation in our data centre. This involves mid-tier appliction servers talking to back end database servers with load-balacing and firewalling involved. There is quite a bit to cover in your post so please come back if needed.
1) Dual-honed servers. Absolutely. I'm assuming you would have redundancy with your switch and router architecture so it would be foolhardy not to include server redundancy.
There are a number of ways to do this. Obviously you connect each server to two different switches. You can run NIC's in active/active mode or active/failover. You can use the same IP address for both NIC's or you can have separet IP's.
In our datacentre we use active/failover (fault-tolerant) and use one IP address for the server. If you are firewalling any of these servers using 1 ip address only makes things simpler.
2) Management vlan. Again absolutely and this becomes even more important if you want to firewall these servers ie.
Lets say for arguments sake you only need to allow ports 80 & 443 through to your mid-tiers. Very easy to firewall. But if you also run your management software on the data NIC's you now have to add in those ports as well and believe me, a lot of server management software was not written with firewalls in mind.
3) We place our mid-tiers on a separate vlan from the database server. Even if this is an internal only application you stil need to protect the database server. Databases often hold some of the most sensitive, critical information within the company. They should be on a dedicated, preferably firewalled vlan.
The mid-tier/database server architecture makes it easier to protect your database server as you can tie the firewall rules down to only all the mid-tiers to initiate connections to the database server.
I don't know what kit you are using but bear in mind layer 3 switching is not going to be a major performance hit especially if you do firewall the back end.
4) Production and dev servers should always be on separate vlans and preferably dev should be firewalled off from production. In an ideal world dev should not even share the same switch infrastructure but this is not always possible.
5) Load-balancing. The mid-tiers have web front-ends running on them. We use load-balancers for
i) distribution of load
ii) protection against failure of individual servers.
You need to talk your apps people to see if they require that sort of load-balancing.
6) Firewalling. It all depends on how secure this needs to be. Your application guys might not be the best people to talk to on this. Maybe you have security guidelines on this ?.
We firewall both the mid-tiers and the database servers. Do we need to firewall the mid-tiers - probably not and even Oracle suggested as much but the project insisted at the time.
Do we need to firewall the database server - absolutely yes.
One thing that is worth doing is talking to the company who sells the application, sitting down with them together with your application guys. They should have some recommended best practices as regards security, and to be honest, if they don't you should be questioning why you are using that application.
HTH, please follow up with any more questions
** Edit - Cisco have some good design docs for data centre infrastructure, please see the following link
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...