So we're finally getting to a point where our simple, single subnet network wants to be broken up. Assume a sales/admin side and a development side. Where should I locate a common file server?
A subnet of its own?
On one or the other subnets?
Multihomed and on both sides?
Performance is not critical and this can really be made to work any way. More interested in the rationale and what will make the most sense going forward.
Since you are segregating your network now, you might as well do it right the first time. Now, your actual end design will depend on your business needs but in general you should have the folling "classes" of networks:
Having your network segmented this way will allow for growth in the future, as well as preventing you from having to give admins access to the developer segment if they don't need it.
If you really think about server placement now while you are going through the pain of migrating already and make allowances for future use, then when the time comes that you need to fully utilize this setup you won't have to completely reconfigure your network yet again.
Depending on usage, really. If one team uses it more than the other, locate it on that subnet. If both teams use it the same, and you have a spare firewall/router, put it on it's own subnet. Don't have a spare firewall or router you can put it behind, or the traffic is very heavy, dual home it.
If you dual home it, you have to think about DNS/access methods for each group to make sure they're using the correct interface, rather than being routed to it.
Basically this is just my own personal opinion...
If you are expecting growth in the future of more "shared" network resources between the two VLAN's you could look at creating a 3rd VLAN specific to those shared resources.
This Vlan could house your File server for now and then any other shared resources later ( more servers / printers / etc )
We segment out our servers partly for organization, but as well, to isolate the backup traffic.
Routing between Vlans is also another way of controlling access with VLan specific ACL's.
The answer really depends on whether your switching and routing environment can easily support VLANs and if you have enough knowledge to deploy them.
If the answer is NO and you are not willing or able to make it YES, then I would make a bigger network (i.e. increase the size of the address space) by changing the network subnet mask. If you are currently using the 10.10.0.1 to 10.10.0.254 space, the subnet mask is 255.255.255.0. If you change the subnet mask to 255.255.254.0, get the space 10.10.0.1 to 10.10.1.254, adding 254 usable addresses.
Note: This is not a good long term solution, but it is a great temporary measure to buy some time. It has downsides, primarily around performance due to more broadcast traffic.
If the answer is (or will shortly be) YES, then my recommendation is ...
1- one VLAN for shared/common resources, such as servers and the internet firewall.
2- other VLAN's as you wish for workstations and other clients. DHCP will be your biggest headache .. it has to be setup for each VLAN. Typically a DCHP server can serve more than one scope, and the VLAN control switch can be told to pass DHCP requests properly.
3- once it is stable, use the central routing device (likely your main switch) to control/secure traffic among the VLANs.
This is a better long term solution, as it can grow and morph without much effort or performance issues.
Odds are good that the users will be accessing a "common file server" with the same protocol. Assuming you're moving to a multi-subnet architecture in order to use ACLs to limit traffic flowing between the subnets, the needs of the "sales/admin" versus "development" to access the file server, from a protocol level, are going to be the same. It ends up being "6 of one, half-a-dozen of the other" from an ACL perspective.
I'd put it in a "common server subnet" and apply an ACL to the inbound / outbound traffic from that subnet that treats all traffic the same regardless of source subnet.
I'd be curious for more background about why you believe your network "wants to be broken up". You shouldn't start subnetting an Ethernet LAN unless you have good reasons to do it. The best two reasons are:
Mitigating performance problems.
A desire to limit / control traffic moving between hosts at layer 3 or above.
I've got an answer that rated fairly highly that I'd refer you to for more commentary.
