A Question About SAN's

[KraftDinner]

So I'm doing some research on SAN's (Storage area networks) and I understand that the two main ways of connecting a SAN to the network is either using iSCSI or Fibre Channel. Now this is pretty easy to understand when were talking about a local SAN (maybe in the same building or same floor) but how would you connect a SAN to your network when its hosted somewhere else, like another building? Would you have to physically run a fibre line from one building to the other? 

 

Mind you I've never seen a SAN before so i'm working off imagination atm lol, please correct me if anything I've said is wrong

[unijab]

Dont forget about FCoE.

Depends on if you plan to have your SAN network separated from the rest of the network or if you plan on just putting it on another vlan... (assuming Ethernet)

If you are using true FC... then you'll probably be running fibre. Unless of course, the destination is too far and you are gonna route it over the internet or something.

[leadeater]

Also don't forget about SAS and SAS switching. More akin to direct attached storage but SAS can be a shared fabric if setup in that manor which I have done a number of times in small 2-4 ESXi host clusters with IBM DS3500/V3700.

Almost every iSCSI initiator and target server do no support routing of iSCSI traffic so for longer distances you just make sure the VLAN trunk path is all setup. Keep in mind this is storage traffic so even very low latency still has a significant impact on performance.

Generally speaking you have the SAN and Servers in the same building and for long distance you have a second SAN at the other location and setup replication between the two so servers are using short paths etc. I should really say storage node rather than saying two SAN's also as the system as a whole is the SAN.

[KraftDinner]

1 hour ago, unijab said:

Dont forget about FCoE.

Depends on if you plan to have your SAN network separated from the rest of the network or if you plan on just putting it on another vlan... (assuming Ethernet)

If you are using true FC... then you'll probably be running fibre. Unless of course, the destination is too far and you are gonna route it over the internet or something.

 

48 minutes ago, leadeater said:

Also don't forget about SAS and SAS switching. More akin to direct attached storage but SAS can be a shared fabric if setup in that manor which I have done a number of times in small 2-4 ESXi host clusters with IBM DS3500/V3700.

Almost every iSCSI initiator and target server do no support routing of iSCSI traffic so for longer distances you just make sure the VLAN trunk path is all setup. Keep in mind this is storage traffic so even very low latency still has a significant impact on performance.

Generally speaking you have the SAN and Servers in the same building and for long distance you have a second SAN at the other location and setup replication between the two so servers are using short paths etc. I should really say storage node rather than saying two SAN's also as the system as a whole is the SAN.

I see, so realistically I am assuming that no matter what technology a company may be using (SAS, iSCSI, FCoE) they would generally has the SAN locally and if they had more than one location the SAN would replicate with the SAN in the other location in order to save bandwith

[leadeater]

53 minutes ago, KraftDinner said:

I see, so realistically I am assuming that no matter what technology a company may be using (SAS, iSCSI, FCoE) they would generally has the SAN locally and if they had more than one location the SAN would replicate with the SAN in the other location in order to save bandwith

Main reason to replicate isn't really to save bandwidth its about I/O latency or commit time. There are two types of replication, Synchronous and Asynchronous, and which you use depends on a couple of factors.

Synchronous:

This method is used when the service using the data must always have the up to date version of the data at both sides of the replication. This method also allows for both sides to be active (active-active) and writable, this spreads the load and can give higher performance. The down side to this is both sides of the replication must confirm the write before the I/O transaction completes so latency is higher. You can do this locally not just long distance for the performance and availability benefit.

Asynchronous:

This is the default method that is chosen in most cases. Each end of the replication are write independent from each other and sync data changes at a set schedule. Only one side is writable at a time (active-passive) and there is no write commit latency penalty. This method is commonly use for disaster recovery purposes or reporting where you are only reading the secondary copy. You can use the data at the secondary endpoint to make an active new clone of the data also, DR testing or for some other purpose.

[KraftDinner]

6 hours ago, leadeater said:

Main reason to replicate isn't really to save bandwidth its about I/O latency or commit time. There are two types of replication, Synchronous and Asynchronous, and which you use depends on a couple of factors.

Synchronous:

This method is used when the service using the data must always have the up to date version of the data at both sides of the replication. This method also allows for both sides to be active (active-active) and writable, this spreads the load and can give higher performance. The down side to this is both sides of the replication must confirm the write before the I/O transaction completes so latency is higher. You can do this locally not just long distance for the performance and availability benefit.

Asynchronous: 

This is the default method that is chosen in most cases. Each end of the replication are write independent from each other and sync data changes at a set schedule. Only one side is writable at a time (active-passive) and there is no write commit latency penalty. This method is commonly use for disaster recovery purposes or reporting where you are only reading the secondary copy. You can use the data at the secondary endpoint to make an active new clone of the data also, DR testing or for some other purpose.

Great, thanks for all the help, I'm 18 and trying to get into networking you've helped me a lot in previous threads as well! May I ask how long you've been in the field you sound very knowledgeable 

[leadeater]

Just now, KraftDinner said:

Great, thanks for all the help, I'm 18 and trying to get into networking you've helped me a lot in previous threads as well! May I ask how long you've been in the field you sound very knowledgeable 

Currently I'm 28, but I've been working with servers since about 12. Benefits from dad also working in IT, got a lot of equipment to use at home. Things like full 4U multi cpu rackmount servers and 24 disk external enclosures etc.

Got my first industry certification at 16, a pointless/useless one mind you (CompTIA A+), then went on to Uni to get a degree in Information and Communication Technologies, again practically useless for real world IT but required to get a decent job non the less. During my degree I also studied Cisco CCNA but never got round to sitting the test, didn't have the money at the time.

One of the things I do to make sure I keep up to date and get practical experience is to have servers at home and operate my network in the same manor a large business would. I have about 200GB of ram, Cisco L3 switching, FortiGate firewalls etc.

[KraftDinner]

3 minutes ago, leadeater said:

Currently I'm 28, but I've been working with servers since about 12. Benefits from dad also working in IT, got a lot of equipment to use at home. Things like full 4U multi cpu rackmount servers and 24 disk external enclosures etc.

Got my first industry certification at 16, a pointless/useless one mind you (CompTIA A+), then went on to Uni to get a degree in Information and Communication Technologies, again practically useless for real world IT but required to get a decent job non the less. During my degree I also studied Cisco CCNA but never got round to sitting the test, didn't have the money at the time.

One of the things I do to make sure I keep up to date and get practical experience is to have servers at home and operate my network in the same manor a large business would. I have about 200GB of ram, Cisco L3 switching, FortiGate firewalls etc.

Wow that's great, it's nice to see someone young so knowledgeable in the IT field, I've currently got my CompTIA A+ (like you said, useless) and my Network+ I'm working on my MCSA (which is the thing that matters) and I've got an internship coming up in April. I want to be the best at what I'm getting into and move up the ranks, do you have any advice for someone of my age just about to enter the field of systems / network administration?

[leadeater]

1 minute ago, KraftDinner said:

Wow that's great, it's nice to see someone young so knowledgeable in the IT field, I've currently got my CompTIA A+ (like you said, useless) and my Network+ I'm working on my MCSA (which is the thing that matters) and I've got an internship coming up in April. I want to be the best at what I'm getting into and move up the ranks, do you have any advice for someone of my age just about to enter the field of systems / network administration?

Just make sure you are knowledgeable in topics you are going to converse with people about, even if it is only a small amount. Basically be careful of making yourself sound stupid or uneducated. Never be afraid to voice your opinion either though. Also there are many people in the field that think everyone should serve their time doing the crap jobs like service desk before being allowed to do 'real IT work'.

Also know when to accept things as they are even when you are technically correct and the other person or procedure isn't. Tons of ridiculous and stupid things in IT that other people force down upon use without any real knowledge in the area (rant off :P).

There are two things that people take notice of very quickly. Being knowledgeable in many areas, doesn't have to be to an expert level, and strong troubleshooting ability. Both these things shows that you have a solid understanding of the fundamentals which shockingly many do not. Too many are isolationists and only know the area they primarily cover i.e. storage and don't know even the most basic things about networking.

[KraftDinner]

3 minutes ago, leadeater said:

Just make sure you are knowledgeable in topics you are going to converse with people about, even if it is only a small amount. Basically be careful of making yourself sound stupid or uneducated. Never be afraid to voice your opinion either though. Also there are many people in the field that think everyone should serve their time doing the crap jobs like service desk before being allowed to do 'real IT work'.

Also know when to accept things as they are even when you are technically correct and the other person or procedure isn't. Tons of ridiculous and stupid things in IT that other people force down upon use without any real knowledge in the area (rant off :P).

There are two things that people take notice of very quickly. Being knowledgeable in many areas, doesn't have to be to an expert level, and strong troubleshooting ability. Both these things shows that you have a solid understanding of the fundamentals which shockingly many do not. Too many are isolationists and only know the area they primarily cover i.e. storage and don't know even the most basic things about networking.

Great, thank you very much for the advice, I'm doing my best to stay educated and up to date with everything. Thanks for all the help.... I'm sure I'll be needing your help again sometime soon haha 

[leadeater]

1 minute ago, KraftDinner said:

Great, thank you very much for the advice, I'm doing my best to stay educated and up to date with everything. Thanks for all the help.... I'm sure I'll be needing your help again sometime soon haha 

Well I can already say from what I've seen you have the required understanding to do the majority of the work a junior system admin/network admin would be doing. What you really need now is industry experience and exposure to IT systems so you can see things like SANs being used in real situations and gather understanding through observation and the hopefully interaction.