Re: [Veritas-bu] Nic Utilization
Hello, We had a simple setup with several file servers (AFS) and one master / media server and one robot with two drives. The file servers and the master / media server were connected via eth0 or bge0 actually to the regular LAN. But eth1 bge1 was connected to a private switch. The afs file servers were configured to only use eth0 or bge0 and the bge1 eth1 nic was assigned a private host name. (/etc/hosts) Netbackup was configured with the clients to use these private names, eg: real name engr06f and then we have engr06f-prv. Netbackup used engr06f-prv, so all the backups went over the private network. I understand this setup is pretty common. The gentleman who set it up in the first place told me that as I inherited it when he moved to greener pastures. :) Now another group runs a bigger netbackup system that we hook into here at NCSU and it has lots of media servers. But now everything (file server stuff and backups) runs on the primary nic and the other ports go unused. But because they have more (virtual) tape drives the backups go much faster because it can run 5 streams for 5 partitions. We don't see issues with the file servers being noticeably slower during backups with the new setup. We're backing up about 2TB of data total with these servers. Hope that helped. Gary Gatling | ITECS Systems ITECS, BOX 7901 | Operations and Systems Analyst NCSU, Raleigh, NC | Email: gsgat...@eos.ncsu.edu 27695-7901| Phone: (919) 513-4572 (5C Page Hall) On Thu, Apr 8, 2010 at 2:33 PM, Heathe Kyle Yeakley wrote: I had a question about how everyone else utilizes the NICs inside your master and media servers. I have 1 master and 2 media. Like most systems these days, I have 3-4 NICs in each one. The administrator that setup our existing environment plumbed 1 NIC per machine, and the other NICs sit there, completely unused. At night, when our backup are running, it isn't unheard of for the NICs on all three machine to reach a high utilization level. This got me to thinking. I've read that you can set an option in the bp.conf file and have various clients backup to different interfaces on the same physical master and/or media server, but I've never actually deployed that feature. I've also heard of a technology called Link Aggregation Control Protocol (LACP) that allows you to tie multiple NICs together to increase the total bandwidth into your server. Does anyone else employ these technologies? Does everyone else just plumb one NIC and let the backups trickle in as fast as the LAN allows? Is there other aggregation technology out there that folks are using to utilize and squeeze more bandwidth out of those unused NICs? Thanks. - Heathe Kyle Yeakley ___ Veritas-bu maillist - veritas...@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] AFS backups / restores with Solaris or Linux
Greetings, Thanks for the suggestion. I tried looking for a NetBackup 5.0 Linux client and I couldn't find one. So thats that. I also tried installing a NetBackup 7.0 server and two 7.0 clients. One on Solaris 10 and one on RHEL 5. I still get tons of fail on Linux with this setup. I actually tried using "strings" to see of I could find and references to vos commands buried within the "bpbkar" executables on either platform. On solaris there were 12 lines of vos commands I could identify. Stuff like this: Not updated since full, skipped running vos dump for %s On the Linux client there were only 2 lines. So it seems the Linux executable was never compiled with many of the AFS features. No wonder it doesn't work! I also tried calling Symantec technical support to report this "bug" and they said I would be getting a call back about this issue. But I am thinking this is just not going to ever work. They sent me to this pdf file that says openAFS support is only for Solaris 8 SPARC. Lovely... EOLed os. I have just found out that it seems that our university is looking into teradactyl (http://www.teradactyl.com/backup-solutions/backup-platforms/openafs-backup.html) since it seems they actually support AFS. Yay. Hopefully this other solution will work out better and we won't have to pay so much for the backup software. Thanks for the replys about this. At least I have an answer now. And the answer seems to be "switch companies" or roll your own solution. :) Gary Gatling | ITECS Systems ITECS, BOX 7901 | Operations and Systems Analyst NCSU, Raleigh, NC | Email: gsgat...@eos.ncsu.edu 27695-7901| Phone: (919) 513-4572 (5C Page Hall) On Wed, 31 Mar 2010, Ron Jack (Systems Network) wrote: > I have zero experience with AFS, so your post piqued my curiosity. Plus, > I'm just down the street, so I thought I'd try to assist a neighbor. > > Total stab in the dark - try the 5.0 client. > > It certainly appears AFS support is dodgy and that Veritas doesn't want > to hear about it. So, yes, most folks seem to split the difference by > scripting out the "vos dump" and backing that up. From the openAFS > mailing list archive: > http://www.mail-archive.com/openafs-i...@openafs.org/msg20079.html > > That link at the top of the page to the scripts still works. Wheel > invented, as it were. > > Ron > > > Gary Gatling wrote: >> Greeetings, >> >> At my work we use several AFS file servers for storage. We have been using >> netbackup to backup and restore these servers for many years. They are >> all running on Solaris 10 on SPARC hardware. >> >> We would love it if it would be possible to switch to using Red Hat >> Enterprise Linux for these AFS servers. The SPARC stuff is just too >> expensive. And their is the uncertanty about Oracle's takover. I do >> actually use RHEL 5 to run some AFS servers that don't need to be backup >> up... >> >> When I last tried setting up a server and doing a backup/ restore with a >> test AFS file server running under RHEL 5, it did not work. Restores from >> a backup done on a SPARC system worked on Linux. But a backup would not >> work. Instead of backing up the /vicepa patition volumes it tried to >> backup all the actual files on the /vicepa partition. On our Solaris and >> Linux AFS fileservers we are using namei type AFS fileservers. >> >> The files have names like: >> >> /vicepa/AFSIDat/R1/R5y0U/+/+/06 >> >> these files contain the actual data that is used by the AFS volumes. It >> shouldn't be backing those up. Instead it should be doing a "vos dump" >> command to copy the .backup volume. >> >> The backup selection in the client is: >> >> /vicep[a-z] >> >> I was wondering how I could go about reporting this bug? Any chance it >> could ever be fixed? I have been told netbackup does and doesn't >> support AFS fileservers any longer... I'd hate to have to cobble together >> our own backup solution when netbackup has been working so well all these >> years. >> >> The versions of netbackup client I tried were: >> >> netbackup 5.1, 7M. >> >> netbackup 6.0, 4M. >> >> netbackup 6.5.3.1. >> >> The version of afs we are using on our servers is 1.4.11. >> >> I was told by a Linux sysadmin I know that this used to work with RHEL 3. >> But he didn't provide any further details such as the version of >> netbackup client it used to work with. >> >> Another group has taken over our backups and soon I will not have access >> to a tape robot any more or a netbackup server. Afte
[Veritas-bu] AFS backups / restores with Solaris or Linux
Greeetings, At my work we use several AFS file servers for storage. We have been using netbackup to backup and restore these servers for many years. They are all running on Solaris 10 on SPARC hardware. We would love it if it would be possible to switch to using Red Hat Enterprise Linux for these AFS servers. The SPARC stuff is just too expensive. And their is the uncertanty about Oracle's takover. I do actually use RHEL 5 to run some AFS servers that don't need to be backup up... When I last tried setting up a server and doing a backup/ restore with a test AFS file server running under RHEL 5, it did not work. Restores from a backup done on a SPARC system worked on Linux. But a backup would not work. Instead of backing up the /vicepa patition volumes it tried to backup all the actual files on the /vicepa partition. On our Solaris and Linux AFS fileservers we are using namei type AFS fileservers. The files have names like: /vicepa/AFSIDat/R1/R5y0U/+/+/06 these files contain the actual data that is used by the AFS volumes. It shouldn't be backing those up. Instead it should be doing a "vos dump" command to copy the .backup volume. The backup selection in the client is: /vicep[a-z] I was wondering how I could go about reporting this bug? Any chance it could ever be fixed? I have been told netbackup does and doesn't support AFS fileservers any longer... I'd hate to have to cobble together our own backup solution when netbackup has been working so well all these years. The versions of netbackup client I tried were: netbackup 5.1, 7M. netbackup 6.0, 4M. netbackup 6.5.3.1. The version of afs we are using on our servers is 1.4.11. I was told by a Linux sysadmin I know that this used to work with RHEL 3. But he didn't provide any further details such as the version of netbackup client it used to work with. Another group has taken over our backups and soon I will not have access to a tape robot any more or a netbackup server. After that I will only have access to the clients. As for the group taking over our backups their blanket answers are: "AFS + netbackup will only be supported and work on solaris 8" which is rubbish since I have many Solaris 10 systems and it works just fine. Solaris 8 was end of lifed so I know using it forever is not a realistic answer either. Our Sun hardware is out of warranty and getting older every day. I know a lot of other services have moved away from UNIX to Linux over the years so it should be possible for this last one of our dependencies to get fixed if symantec still supports afs. Thats the big "if" I guess. I tried asking about this topic on the openAFS mailing lists but was told symantec didn't care about AFS support on Linux and that we should cobble together our own solution. I fear this is not an option and that in the end taxpayers dolars will be wasted on expensive Sun hardware if this is the only asnwer. We also can't dich AFS yet. Thanks for any ideas anyone might have. Gary Gatling | ITECS Systems ITECS, BOX 7901 | Operations and Systems Analyst NCSU, Raleigh, NC | Email: gsgat...@eos.ncsu.edu 27695-7901| Phone: (919) 513-4572 (5C Page Hall) ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu