On 23/12/2010, at 6:32 PM, Jake Anderson wrote: > On 23/12/10 18:11, James Gray wrote: >> 5. This leaves DNS, SNMP/Cacti, and Squid on Jester. >> >> Now migrating my remaining setup (#5) to a single 8GB SSD is where I'm a >> little stuck. >> >> The QNAP supports both iSCSI and NFS, so I was thinking I could use the SSD >> for /boot and the root fs, then mount the rest from NFS and/or iSCSI. The >> kicker is; how? How do I migrate this stuff with minimal fuss? I was >> considering just creating the iSCSI/NFS mounts, rsync all the data over >> (permissions and everything of course), then drop to single user (or busybox >> etc) and change the mounts to use the iSCSI/NFS instead of the LVM mirror. > Any particular reason for using iscsi or nfs to mount local data? (your going > to have to mount stuff to share it over nfs anyway, might as well use it) > I mean all the drives are inside the box just mount/symlink them where you > want. > no overhead and simpler on your brain.
Though about this approach, but I have two reasons for not going this way: I actually slice up my boxes into more than just rootFS, /boot and swap, so symlinking /usr, /home, /var, etc ... would be pretty evil! Secondly, I've never really played much with network-hosted system volumes and really want to play with stuff like /home on NFS and swap on iSCSI etc. >> So, now we have all the non-rootFS and non-/boot stuff taken care of. Next >> I rsync the rootFS and /boot onto the SSD (yes, they will fit inside >> 8GB...with room to spare): > I'd just make / the SSD and include boot with it, then symlink out any actual > data storage needs (/var/lib/mysql say), perhaps make a partition on your > raid for /home. > (personally I'd use a larger than 8gb SSD but your call) > also I'd think about making a few small non raided partitions on your drives, > I use them for the various tables for mythtv (different tables different > spindles), complete overkill to be sure but ey, why not ;-> Not sure we're on the same page here. The QNAP (think "network storage") will be hosting everything OTHER than rootFS and /boot. The SSD will only have /boot and rootFS. Hence "slim" server as opposed to pure "thin" server. My distinction between the two: thin - no local storage at all. Pure net-booting, net-storage. slim - local storage for booting and root file system. All *other* storage on the network. >> This leaves GRUB and swap. How the heck do I tell GRUB that the SSD is now >> "groot=(hd0,0)"?? Or is this not important once I rip out the 2x500GB drives >> leaving only the SSD?? > just reconfig grub, if its grub2 under ubuntu there is a nice menu system > that lets you install it on all drives, you just need to tell it where /boot > is, its a bit of a sequence, booting off a livecd or some such generally. Cool - been a while since I've messed around with boot loaders (ah the good ol' LI202020202020.... days! heheh). I'll dig around the Ubuntu-sphere for some more info. >> PS - once jester is doing basic snmp/cacti/squid/etc and the QNAP doing the >> "heavy-lifting", I intend under-clocking the little dear from 2.66GHz to >> about 1.6GHz :) Save the planet and all that. > I wouldn't under clock it, it should support dynamic clocking (one presumes) > that will drop the clock pretty low when idle, then bump it up when in use. > This often will save power as the CPU can stay in low power "sleep" states > for longer, at least on the smaller end of the scale. Yep - will do that as well as under-clocking (which is the plan). THe under-clocking will also reduce heat and power on the FSB etc. too, which wouldn't happen with dynamic scaling alone AFAIK. Happy to be proven wrong on this as the CPU barely breaks out of "brrr, I'm freezing, can someone please do something to warm me up" mode, and rarely heats up much beyond ambient, so if I can avoid the under-clocking....GREAT! The two 15k RPM 3.5" 500GB drives though, they generate a metric truck load of heat!! Hence the reason I'm ditching them for an SSD and external NAS. Thanks for the insight Jake! Cheers, James
smime.p7s
Description: S/MIME cryptographic signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
