User Functions
Don't have an account yet? Sign up as a New User
Who's Online
Guest Users: 7
|
| View previous topic :: View next topic |
| Author |
Message |
macucation
JBOD
Joined: 01 Sep 2009
Posts: 4
|
 Posted: Fri Sep 18, 2009 3:06 pm Post subject: Vlan for Private metadata network |
 |
|
| i am in a windows environment and have about 50 macs which i support. I am currently setting up an xsan solution for 3 editing suites. The network admin told me that he was going to create a vlan on an already used cisco switch for the private network. Has anyone tried this or know if this works. I am hesitant and do not want to go through with it if it is not even worth it. Any feedback is appreciated. |
|
| Back to top |
|
 |
jtownsend
Xsan Master
Joined: 24 Feb 2008
Posts: 74
|
|
| Back to top |
|
|
MattG
Xsan Master
Joined: 15 Apr 2005
Posts: 456
|
| Posted: Sun Sep 20, 2009 11:28 pm Post subject: |
|
|
| You provide yourself with another troubleshooting variable when using VLANs, especially if there are performance or file access latency issues. Best practice is to put the metadata net on its own physical switch(es). |
|
| Back to top |
|
|
JesusAli
Xsan Master
Joined: 25 Jul 2008
Posts: 151
|
| Posted: Mon Sep 21, 2009 9:05 am Post subject: |
|
|
I think VLANs are not "Golden Master Fantastic"... but they are workable.
My XSan is the case in the thread that JTownsend linked to.
We are now up and running with acceptable latency.
* * *
In our case, there is a "Tech Closet" between the Xsan Clients and Main Server room. A tech closet is a satellite server room.
My two MDC's are in the Main Server room along with the Sanbox Fiber Switches and all fiber termination.
But the NICs for my 17 Xsan Clients all terminate in the Tech Closet, in a Gigabit switch I obtained as part of the Xsan Install.
That gigabit switch has a Fiber Uplink to get back to the core in the server room.
The MDC's plug into that core.
So from physical necessity, my Private and Public networks are split across (at least) two separate physical switches.
So in my case, using VLANs actually HELPS keep the data packets associated with themselves as they cross over different switches.
You program the VLAN on the core, and it propagates the VLANs to other switches. And your packets are then tagged as they move along.
VLANs could be thought of like "Commuter Lanes" on the freeway.
You can impose limits on VLANs in terms of what traffic they will and won't allow. Like, "Hybrid Only" commuter lanes.
So you can block out extraneous network noise and pings to keep the lanes as clear as possible.
* * *
I just Screen Shared into my MDC01 (hosting my xsan volume) and had its Terminal ping the same Xsan Client on both the public and private networks. The private is VLAN'ed.
Here's a short average:
| Code: | --- 172.20.9.220 ping statistics --- (PUBLIC)
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.467/0.582/0.709/0.076 ms
--- 10.20.9.220 ping statistics --- (PRIVATE, VLANed)
14 packets transmitted, 14 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.342/0.485/0.617/0.078 ms |
Bear in mind that is at an art college of 650 students, at 9AM on a Monday morning. We're running about 100 AFP network account logins right now, and probably 80 of those students are on Facebook right now, probably 40 have large Photoshop files open from their AFP Network account, ect.
During the lunch hour or maybe an hour afterward, I would expect network traffic to get even more dense. I sort of expect the Public Network's latency to get worse, but I expect the Private's to stay the same.
* * *
In summary, I would review the thread JT linked to, understanding that following its advice, (especially stuff toward the end of the thread in terms of what traffic to allow or turn off on the VLAN) produced the generally acceptable numbers presented here. You might even have your Network Admin take a look at the thread.
For instance, it discusses how "QoS" (Quality of Service) can raise the importance of a VLAN so that its packets get higher priority over others. The thread mentions that being employed in some Xsan solutions, but I asked my Network Admin and he said, No. He said that we use QoS for the Cisco digital IP phones. Which I can understand.
Good luck. Please follow up with how things go. |
|
| Back to top |
|
|
abstractrude
Xsan Master
Joined: 13 Mar 2008
Posts: 881
|
| Posted: Mon Sep 21, 2009 5:52 pm Post subject: |
|
|
well implemented it work perfectly.
poorly implemented it will burn xsan to the ground |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
Xsanity Forum
Forum Search
Forum Help
Log in to check messages
Xsanity Articles
