I don't know on the Hitachi SANs, but for the Sun ones there are step by step guides on their website, have found a whitepaper by Micrpsoft which might help Simple SAN White Paper
Our SAN arrived today [ hitachi san 100 ] - now the last time I setup a SAN was over 8 years ago and fiber was the way to connect it. I want to do this via ISCSI and on a different subnet. I setup our current network on a 10.0.0 range and understand I will need to have additional network cards in our servers going into a separate switch etc.
Can anyone point me to a step by step guide or highlight a good book to get on the subject ?
Thanks - will take a look.
If multihoming domain controller watch out.
What version of Windows are you connecting to the SAN? You need to make sure Microsofts iSCSI Initiator is installed and set up. I believe it is built into Windows Server 2008 R2. Other whys it's a free download - http://www.microsoft.com/downloads/d...displaylang=en
there is a user guide doc on the same page.
IIRC - you make sure the Hatachi can see/connect to the Windows box via it's iSCSI Initiators unique WWN name. You then attach whichever LUN's on the SAN to that PC's connection on the SAN. Then on the PC side, if all as gone well, you just refresh Disk Management and the LUN will automagically appear like anyother Windows hard drive.
When I did it last I was using SANMelody rather than Hatachi so I don't know the exact setting on your SAN box, just the general principal. Also I didn't use any authentication between iSCSI connection. I think you are supposed to use CHAP to authenticate the connection between the PC and the SAN.
If you are using a totally seperate switch and all servers that will be accessing the SAN have a seperate LAN card to connect to that switch then there isn't a great deal to do. Pick a new IP range that doesn't conflict with the rest of your network - I like 172.16.0.0/255.255.255.0 because it's rarely used. Give the SAN and each SAN connected nic an IP in this range. When setting up the NIC's make sure you don't specify any dns or default gateway settings - these should only be set on the server primary nic on the main LAN - and also check in the nic properties that 'Windows Network' is unticked. It's not needed and as Plexar point out above can cause problems and confusion within Windows.
Also don't attach any SAN LUN to more than one Windows Server - Windows 2003 doesn't natively support cluster shared volumes and you'll be in for a world of pain.
If you are using a switch on your main network to run the SAN over, make sure it supports VLAN's and make sure the ports that the SAN nics connect to from the servers and the Hatachi SAN are all on the same VLAN number. You may want to check the NIC's setting for a VLAN tagging option and make sure they are all set to the same VLAN number as the switch ports.
The rest of your network should be accessing the SAN through one of the servers connected to the SAN - perhaps as Windows Folder Shares, or whatever is required.
I have have plans on turning this into a Virtual Server at some point along with a few others so don't want to connect it unless I really have to.
You only need to connect any computer to a SAN if you need to allocate hard drive space, a LUN, from the SAN to that computer. If the WSUS server doesn't need any more hard drive space, if you are not planning to allocate it any space on the SAN, then it doesn't need connecting up.
The best way to think of it is like this - A LUN on the SAN is the equivilent to a SCSI/SAS/SATA/IDE hard drive that you plug directly into a computer/server. A computer/server is given direct access to the SAN only if they are in need of an additional hard drive and you want to allocate that extra hard drives worth of space from the total storage available within the SAN.
For every other server/computer they access resources stored on the SAN via shares, databases, etc, hosted on one of the servers that are directly connected to the SAN.
You mention Virtual Servers, What virtualisation tech are you looking at or using?
I set ESX 3 up on a SAN and I found it quiet painless. The disk file format ESX formats SAN LUN's with is natively cluster aware - infact VWare designed the datastore file format especially with this in mind - so you can connect ESX LUNs on the SAN to as meny ESX hosts has you have connected to the SAN Network. This means that all ESX hosts will see all the VM Images stored on all the LUN's. Makes migrating VM's from one server to another a doddle. Lit. just stop the VM on one server and press play on another. If only Windows Cluster Volumes worked with more than just Hyper-V and were as easy to set up!
If I go down the seperate switch / subnet route [ which I think I will ] - then what Subnet does the managed switch need to be on, the new one for the SAN or the exisiting one for the domain ?
Our San switches our on the same rang as our sans which is different to our main network. We have the 100's. Each controller with an ip on the same range as the switches then got iscsi targets on separte nics to our esx host then just add them to our vms
let's start with some simplification - do you need a managed switch?
Let's see, you'd probably get away with an IP on your standard range and linking the managed switch to your standard LAN. I'd say to do it properly the managed switch would need to support VLAN's so you have the SAN traffic on one VLAN seperate from the uplink port for switch management on no VLAN. So the only traffic going along the uplink port between a standard infrastructure switch and the SAN switch is management traffic.
I can't, yet, see a way of making it work using an IP in the SAN range.
There are currently 1 users browsing this thread. (0 members and 1 guests)