Directly connect iSCSI san to EV server
I read from here that people had direct connected their iSCSI san to the EV server and it works for them? I am no networking expert but I was wondering if the iSCSI san is directly connected to the EV server, would the SQL server be able to read/write to the SAN through the EV server if the SQL and EV servers are connected to the same switch, in the same network? or I must have a switch between the EV server and the iSCSI san? can someone help take a look below and they will work please?? or if I need to anything else? or change anything?
THANK YOU!
Directly connected to SAN
LAN
|
|
EV server -----------gbs switch ---------SQL server
|
|
|
iSCSI SAN
OR
LAN
|
|
EV server ----(vLAN)gbs switch (vLAN)-----SQL server
(vLAN)
|
|
|
iSCSI SAN
Any help would greatly appreicated it!! Thanks!
Comments
The 2nd drawing is the ideal
The 2nd drawing is the ideal config. The SQL server cannot go through the EV server to access the storage.
Make sure that the iSCSI traffic goes through it's own dedicated VLAN or switching infrastructure. Oh and Jumbo frames are your friend!
There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."
Agreed turn on Jumbo Frames
Agreed turn on Jumbo Frames it will make life easier for you. And the second option is the normal way of doing this but option one will also work if you use a crossover cable between the iSCSI storage and your EV server and then put them on a private network 192.168.x.x
Liam Finn
thanks for your response, the
thanks for your response, the iSCSI san I am looking is the Dell MD3000i and it has two 1gb ports on each controller, so if I do this...will it work?
LAN
|
|
Switch
/ \
/ \
/ \
(4ports)EV server SQL server (4ports)
\ \ / /
\ \ / /
\ / \ /
ctrler1 ctrler2
iSCSI SAN
Thank you!
It's all iSCSI
The iSCSI disk considerations are not different than they would be for any other application using block based storage. You would generally place the NICs (dedicated or shared) on a switched VLAN to isolate traffic. You *could* use a crossover cable, but that is not very flexible and it kind of defeats the intent of centralized storage. Whichever you choose, the initiator (the EV or SQL server) will need to be able to ping the target storage. The chosen ports should not be blocked, typically iSCSI uses TCP ports 860 and 3260. You also want to make sure the initiator mapping is correct. Sometimes this is referred to as an initiator group or a LUN mask. It is somewhat analagous to an access control list on a file. Unless you are doing any clustering or using USL for failover, each LUN will have only one host at a time with access.
These considerations are invariant of the underlying storage platform. The same concepts exist on NetApp, EMC, Dell, HP, etc. Many vendors supply host agents and support tools that will assist you with the host setup, provide diagnostic support and even interface with your existing management toolsets. Additionally, you should be able to "thin provision" the storage to avoid a large capital expenditure on day 1. This would allow you to "tell" the EV or SQL server it has 1TB available for use, although you might have really only allocated 200GB. Think of this as the way Yahoo or Gmail works. When you sign up for your account with a 1GB mailbox quota, they don't run out and purchase another 1GB disk. Thin provisioning is the same concept. These are some of the advantages you get with a modern SAN and NAS.
Careful with thin
Careful with thin provisioning. Without good reporting tools, and being proactive, it's a bad idea.
Think of it not like email, but travel airlines... They have statistical reports going back decades, down to the time of day, to flights, etc.. They have a good idea of how many people will be on a plane, and how many people will not show up. Based on that, they sometimes overbook the planes. And sometimes, all the people show up.
Thin provisioning is the same way... You need to know how your application data grows, you need to have trends for it. You can plan for an application needing xxx GB in 3 yrs, but today, it only needs x GB. It's possible that a spike in data, could make that volume grow past it's allocated space sooner than 3yrs, and you need to have contingencies in case that happens.
There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."
Thank you very much for your
Thank you very much for your reply. I was wondering if you know if there is any performance differences between using dedicated switches and vLAN?
Thank you teiva-boy, ryujin,
Thank you teiva-boy, ryujin, and scanner001 for your advices. This is my first time deploying EV so there's a lot of things I still don't know even though I passed the EV 8.0 STS exam. I am in the planning stage right now.
ideally I want to do this
LAN (AD, Exchange, etc)
|
|
Switch
/ \
/ \
/ \
(4ports)EV server SQL server (4ports)
\ \ / /
\ \ / /
\ / \ /
switch1 switch2
\ \ / /
\ \ / /
\ / \ /
(2 1gb ports)ctrler1 ctrler2 (2 1gb ports)
iSCSI SAN
but since we have a DR site (fault tolerance is critical to us) , we would need 2 of each device and that's expensive as it is so I am trying to see if I can cut out the switches and still be able to achieve the same optimized performance. but we might have a few ports available on our existing catalyst, is there any performance differences between using dedicated switches and vLAN? or as long as the network traffic is reserved between EV, SQL, and SAN then performance wouldn't suffer?
I plan to have 1 EV server, 1 SQL server (both on physical machine) and for storage, I will allocate 10TB to start off with and add on more enclosure as it required.
Thank you so much!
Would you like to reply?
Login or Register to post your comment.