If your system is easy to administer, it will have good uptime. What’s more, you’ll find it easy to get help and resources from operations. On the other hand, if your system is difficult or annoying to administer, it will be neglected, deprecated, and probably implemented incorrectly. It might even get sabotaged.
It is usually impractical to have QA's environment match exactly with Production's -- otherwise they would be production. Typically, the cause of a testing failure is a mismatch in topology between QA and production. Topology is the number and connectivity of the servers and applications. If you consider each server and application instance to be a node and each connection or dependency to be an arc, you can define a graph that represents the system topology. It usually costs too much to make QA's toplogy match Productions.
Keep Them Separated
Avoid sharing hosts between applications. Certain class of bugs get hidden when applications run co-located on the same server. Use a virtualization solution to give each application its own host. It is a cheap way to emulate the production topology.
Zero, One, Many
If you are going to run a dozen instances in production, you probably don’t need to run a full dozen in QA. You should definitely run more than one, however. Virtualization is, again, a great tool here.
Just Buy the Gear
Hours of downtime due to firewalls and load balancers that didn't exist in QA exceeds the cost of purchasing that gear for QA. Don't be penny wise and pound foolish.