Ideas for distributed Samba servers
in [Samba]
|
Prev: [Samba] Upgrading 3.2.15 to 3.3.12 sernet package on opensuse 10.2
Next: RHEL 5 compilation of Samba 3.5.2, termcap library problem, use '--no-as-needed'
From: Robert LeBlanc on 11 Apr 2010 21:20 On Sun, Apr 11, 2010 at 9:03 AM, ravi channavajhala < ravi.channavajhala(a)dciera.com> wrote: > WAFS (Wide Area File System) appliances can be very well deployed for this > sort of thing precisely. Unfortunately, I don't know of any opensource > project for WAFS. However, commercial solutions such as Riverbed, Expand > Networks, CISCO/WAFS, Juniper/Peribit do exist. > > So far, this is the direction that we may go. We have looked at a Riverbed product, it's good to know alternatives. This may not be as much of an issue as it was in the past as I believe we my get a network upgrade that will negate the need for this. Thanks, Robert LeBlanc Life Sciences & Undergraduate Education Computer Support Brigham Young University -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Stan Hoeppner on 11 Apr 2010 21:50 Robert LeBlanc put forth on 4/11/2010 8:19 PM: > On Sun, Apr 11, 2010 at 9:03 AM, ravi channavajhala < > ravi.channavajhala(a)dciera.com> wrote: > >> WAFS (Wide Area File System) appliances can be very well deployed for this >> sort of thing precisely. Unfortunately, I don't know of any opensource >> project for WAFS. However, commercial solutions such as Riverbed, Expand >> Networks, CISCO/WAFS, Juniper/Peribit do exist. >> >> > So far, this is the direction that we may go. We have looked at a Riverbed > product, it's good to know alternatives. This may not be as much of an issue > as it was in the past as I believe we my get a network upgrade that will > negate the need for this. I would think it would be cheaper and more straight forward to replace the GbE port on each end of the fiber link with a 10GbE port than to deal with the complexity of caching and replication, or other such options, especially for two buildings on the same campus. The fiber link is on campus and thus you control any right-of-way issues, correct? If this is the case, upgrading the link speed on the fiber is definitely the way to go. If multiple pairs were run when the line was originally trenched, as is customary, setup ISL bonding of two 10GbE links between the two buildings' switches. Problem solved. Make sure you have at least one 10GbE NIC (preferably two NICs bonded) in the Samba server that exports the data on the disk array or the fat pipe between the buildings won't matter much. It will be interesting to see what Samba bottlenecks you run into after you get the big phat pipes setup. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Robert LeBlanc on 11 Apr 2010 22:10 On Sun, Apr 11, 2010 at 7:47 PM, Stan Hoeppner <stan(a)hardwarefreak.com>wrote: > > I would think it would be cheaper and more straight forward to replace the > GbE port on each end of the fiber link with a 10GbE port than to deal with > the complexity of caching and replication, or other such options, > especially > for two buildings on the same campus. The fiber link is on campus and thus > you control any right-of-way issues, correct? > > If this is the case, upgrading the link speed on the fiber is definitely > the > way to go. If multiple pairs were run when the line was originally > trenched, as is customary, setup ISL bonding of two 10GbE links between the > two buildings' switches. Problem solved. Make sure you have at least one > 10GbE NIC (preferably two NICs bonded) in the Samba server that exports the > data on the disk array or the fat pipe between the buildings won't matter > much. > > It will be interesting to see what Samba bottlenecks you run into after you > get the big phat pipes setup. > > Although the buildings are on the same campus (multiple buildings about 8 total that we occupy and only parts of building for most of the buildings) we don't have control over the network. That is in the hands of the campus IT organization and they like things done a certain way. We can light some fibre, but it's only point to point and we don't have that much fibre running to our building to connect all the buildings, plus the expense would be astronomical as we can't tie into their network and so connection in the other buildings would be limited. Since they are finally deciding to upgrade the core switching to 10GbE, they are possibly putting our building on the list to get a 10GbE link first. I think that would alleviate the biggest part of the problem, as we suspect that most of the storage will sit idle and not really accessed. Since all the desktops are only running 100 Mb connections, it gives us enough concurrent connections that we feel comfortable with. Robert LeBlanc Life Sciences & Undergraduate Education Computer Support Brigham Young University -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Adam on 12 Apr 2010 00:20 Ever heard of glusterfs? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Robert LeBlanc on 12 Apr 2010 00:30
On Sun, Apr 11, 2010 at 10:18 PM, Adam <squeezer99(a)gmail.com> wrote: > Ever heard of glusterfs? > Yes, I don't think it works well in a geography diverse clusters though. Lustre has this same problem. I could be wrong. Robert LeBlanc Life Sciences & Undergraduate Education Computer Support Brigham Young University -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |