rpm -ivh DDBoostFS-1.2.0.1-595646.rhel.x86_64.rpm<\/strong> \nPreparing... ########################################### [100%]<\/pre>\n(Rest of output removed.)<\/p>\n
For Linux, you’ll need to ensure you have the fuse and fuse-libs packages installed, as well. They’re prerequisites of BoostFS on Linux. (After I installed the plugin, I also edited my root user’s .bash_profile to add \/opt\/emc\/boostfs\/bin<\/strong> to the execution path.)<\/p>\nConfigure the Boost Plugin<\/h1>\n
If you go into the \/opt\/emc\/boostfs\/etc directory, you’ll find a sample boostfs.conf file. You can either choose to edit this file to suit what you need to do, or create it from scratch, following the installation guide. I chose to create it from scratch, and my resultant file looked like the following:<\/p>\n
[root@midkemia ~]# cat \/opt\/emc\/boostfs\/etc\/boostfs.conf<\/strong> \n[global]\ndata-domain-system=neutronium.turbamentis.int\nstorage-unit=BoostFSMidkemia\nlockbox-path=\/opt\/emc\/boostfs\/lockbox\/boostfs.lockbox\nlog-enabled=true\nlog-level=info\nlog-dir=\/opt\/emc\/boostfs\/log\nlog-file=output.log\nlog-maxsize=100\nlog-rotate-num=4\n\n[\/neutronium\/boostfs]\ndata-domain-system=neutronium.turbamentis.int\nstorage-unit=BoostFSMidkemia\nsecurity=lockbox\nmtboost-enabled=true\nmtboost-threads=16\nmax-connections=128<\/pre>\nBoostFS can authenticate in one of two different ways: lockbox, and Kerberos. I chose to use the lockbox format, which required the following commands to setup:<\/p>\n
[root@midkemia etc]# boostfs lockbox set -u boost -d neutronium.turbamentis.int -s BoostFSMidkemia<\/strong>\nEnter storage unit user password: frozenWeaselsTasteFunny<\/em><\/strong>\nEnter storage unit user password again to confirm: frozenWeaselsTasteFunny<\/em><\/strong>\nLockbox entry set<\/pre>\n(No, that’s not really the password I used, and I’m sorry if I’ve picked your random password there.)<\/p>\n
The Lockbox can be shared amongst multiple hosts. I only wanted to use it on my current host, but to be on the safe side I ran the host access command as well:<\/p>\n
[root@midkemia etc]# boostfs lockbox add-hosts midkemia<\/strong>\nLockbox add host(s) completed<\/pre>\nIn the configuration file, I’d specified that I’d be mounting the storage unit I’d created at \/neutronium\/boostfs, so that had to be created:<\/p>\n
[root@midkemia etc]# mkdir -p \/neutronium\/boostfs<\/strong><\/pre>\nWith this all done, I was ready to mount the filesystem:<\/p>\n
[root@midkemia etc]# boostfs mount \/neutronium\/boostfs<\/strong>\n\nmount: Mounting neutronium.turbamentis.int:BoostFSMidkemia on \/neutronium\/boostfs\n\n[root@midkemia etc]# df -h<\/strong>\nFilesystem Size Used Avail Use% Mounted on\n\/dev\/mapper\/vg_midkemia-lv_root\n 21G 3.0G 17G 15% \/\ntmpfs 939M 0 939M 0% \/dev\/shm\n\/dev\/sda1 477M 69M 384M 16% \/boot\nboostfs 354G 19G 335G 6% \/neutronium\/boostfs<\/pre>\nThere you go!<\/p>\n
Go Nuts with the Awesome Potential of BoostFS<\/h1>\n
Right, once you’ve got the filesystem mounted, you may want to make sure that you’re really getting distributed segment processing taking place \u2013 i.e., getting client side Boost running. This is actually pretty straight forward \u2013 all you need to do is copy some files into the mount point while watching your stats on the Data Domain.<\/p>\n
To test this out, I created a tar file of \/usr on the server, as \/tmp\/usr.tar, and prepared to copy that into the mounted Boost directory.<\/p>\n
[root@midkemia ~]# du -hs \/usr<\/strong>\n2.2G \/usr\n[root@midkemia ~]# tar cf \/tmp\/usr.tar \/usr<\/strong>\ntar: Removing leading `\/' from member names\ntar: Removing leading `\/' from hard link targets\n[root@midkemia ~]# du -hs \/tmp\/usr.tar<\/strong>\n2.1G \/tmp\/usr.tar<\/pre>\n(That’s not compression, that’s just tar being a bit more efficient on storage given it’s lumping all the content into the same file.)<\/p>\n
Now, to monitor the Boost protocol in action, I opened a ssh session onto the Data Domain server as the ‘sysadmin’ user, and prepared to run the following command:<\/p>\n
sysadmin@neutronium# ddboost show stats interval 2 count 100<\/strong><\/pre>\nThe goal was to run that command while the copy was taking place, the copy command being:<\/p>\n
[root@midkemia ~]# cp \/tmp\/usr.tar \/neutronium\/boostfs\/<\/strong><\/pre>\nSo nothing special there – I’m not trying to do anything fancy, I just want the file copy to take place. While the copy was taking place, this was the output from the “show stats” command. (Note that the spacing is exactly per the output of the command, pasting it into the blog window removes all spaces and I’ve got to manually add them back in!)<\/p>\n
sysadmin@neutronium# ddboost show stats interval 2 count 100<\/strong>\n07\/30 01:01:18\nBackup Post-comp Network Restore Network Backup Restore\nKB\/s Written KB\/s In KB\/s KB\/s Out KB\/s Conn Conn \n--------------- --------------- --------------- --------------- --------------- ------- -------\n 0 0 0 0 0 0 0\n 5,817 280 280 0 0 1 0\n 48,360 7,039 7,041 0 0 1 0\n 77,083 6,045 6,047 0 0 1 0 \n 73,787 7,237 7,239 0 0 1 0\n 56,310 2,178 2,178 0 0 1 0\n<snip>\n 50,389 6,846 6,847 0 0 1 0\n 1,654 343 343 0 0 0 0\n 0 0 0 0 0 0 0\n^C<\/pre>\nHang on, what witch-craft is that? This is the first copy, and I’m already getting deduplication? Well, there’s a couple of reasons of course \u2013 deduplication starts from the first chunk of data you send to a Data Domain, of course, but even more so in this case, I’ve been using this Data Domain for NetWorker backups of Linux systems<\/em>, so a lot of data it’s seeing here (given tar does not compress) is the same as content it already has on the system. And because deduplication is global, it doesn’t matter that the content has already been stored by NetWorker.<\/p>\nIn fact, we can check on what sort of deduplication we achieved:<\/p>\n
sysadmin@neutronium# ddboost storage-unit show compression BoostFSMidkemia<\/strong>\n\nList of files in BoostFSMidkemia and their compression info:\n\nusr.tar:\nTotal files: 1; bytes\/storage_used: 5.1\n Logical Bytes: 2,201,384,960\n Original Bytes: 2,208,642,332\n Globally Compressed: 799,457,063\n Locally Compressed: 427,029,578\n Meta-data: 3,330,296<\/pre>\nAnd to prove the point, I copied the file again, giving it a new filename on the Data Domain, resulting in the following stats (abbreviated, again):<\/p>\n
sysadmin@neutronium# ddboost show stats interval 2 count 100<\/strong>\n07\/30 01:13:35\nBackup Post-comp Network Restore Network Backup Restore\nKB\/s Written KB\/s In KB\/s KB\/s Out KB\/s Conn Conn \n--------------- --------------- --------------- --------------- --------------- ------- -------\n 7,768 0 0 0 0 1 0\n 71,879 0 0 0 0 1 0\n 69,936 0 0 0 0 1 0\n 67,928 0 0 0 0 1 0\n 69,935 0 0 0 0 1 0<\/pre>\nAnd that’s really all there is to it. With that effort, I’ve got a source-side deduplication mount point from my Data Domain, ready for database dumps, file copies, etc. Of course, BoostFS isn’t about replacing say, a NetWorker or Avamar client, but it will give you an option when you need to provide protection for something more esoteric than a conventional client \u2013 e.g., a NoSQL database, etc.<\/p>\n
I’ll be leveraging the install I’ve done here in an upcoming blog post when I try out OAP \u2013 stay tuned for that.<\/p>\n","protected":false},"excerpt":{"rendered":"
Intro One of the things I’m keen to try in NetWorker 18.1 is the new Orchestrated Application Protection (OAP) feature…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6,1181,9],"tags":[1243,1460,275],"class_list":["post-6983","post","type-post","status-publish","format-standard","hentry","category-basics","category-data-domain-2","category-databases","tag-basics","tag-boostfs","tag-data-domain"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1OD","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6983","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=6983"}],"version-history":[{"count":4,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6983\/revisions"}],"predecessor-version":[{"id":7345,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6983\/revisions\/7345"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=6983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=6983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=6983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"BoostFS](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/07\/BoostFS-Windows-Linux.png\")
<\/a>