Good morning all,
There's a minor update to the S7000 application layer.
You can find it here:
Software Updates - Fishworks - wikis.sun.com
does still has a limitation on number of logzilla ? Should have been 12 for a cluster , 6 on each node , and 18 for a single unit.
you can have up to 6 ReadZilla SSDs per S7310/S7410 and up to 16 LogZilla SSDs as well. The ReadZilla SSDs sit in the controller head and the LogZilla SSDs site in the disk trays. You can have a maximum of four LogZilla SSDs per tray and a maximum of 16 LogZilla SSDs per system. You need to plan how many LogZilla SSDs you will need as currently adding them after you have created your zpool is problematic.
for performance information on the S7000 and the use of SSDs have a look here: Brendan Gregg
if you need to chat about this or need more information drop me a message or call me via the number below.
which document contains the informations ?
Also how many pools can you create with 12 jbods ?
on the S7310 and S7410 the smallest zpool you can create is using 1/2 a JBOD. There are some things to remember though when creating these zpools. Of course RAID is a very important factor when deciding what applications you're going to server out from your nice new Oracle storage :-)
The LogZilla SSDs are associated with a zpool so when you're creating your multiple zpools you'll need to be mindful of how many you have (SSDs) and what ones you want / need to associate with a zpool. For example, you want to put Exchange on the S7000 so you create a mirrored zpool and because Exchange creates synchronous writes (ZFS - the file system on the S7000 understands synchronous writes and will always point them at the LogZillas for maximum performance) you associate a couple of the LogZillas with that zpool. For a standard directory structure for say student data you might just go with a standard RZ2 (RAID 6 equivalent) and no SSDs.
In theory then, with a 12 tray S7410 you could create 24 zpools but that would not necessarily be the best use of your storage and there is a limit of 16 LogZilla SSDs per S7310 / S7410 so you'd run out fairly quickly (plus they're fairly expensive - but very fast too!). My recommendation is to stick to as fewer zpools as you think you need. You can have multiple shares and LUNS in a zpool and can serve out iSCSI, FC, CIFS, HTTP, etc., from a single zpool so there shouldn't be that many problems.
Hope this helps.
The above applies only to clustered config , for single unit the limit is 6you can have up to 6 ReadZilla SSDs per S7310/S7410 and up to 16 LogZilla SSDs
as well. The ReadZilla SSDs sit in the controller head and the LogZilla SSDs
site in the disk trays.
You can have a maximum of four LogZilla SSDs per tray and a maximum of 16
LogZilla SSDs per system.
LogZilla SSDs per system.
Phil,You need to plan how many LogZilla SSDs you will need as currently adding
them after you have created your zpool is problematic.
this is the real problem my consideration if I start with 1 or 4 logzilla/tray :
1 logzilla with trays 1-4 i will have 74 data disks , 18 spares , 4 logzilla
0 logzilla with trays 5-8 i will have 151 data disks , 37 spares , 4 logzilla
0 logzilla with trays 9-12 i will have 228 data disks , 56 spares , 4 logzilla
worst case performance disk/ssd ratio
for 2 pools is 37/2 , 75/2 and 114/2
for 4 pools is 18/1 , 37/1 and 57/1
4 logzilla with trays 1-4 i will have 64 data disks , 16 spares , 16 logzilla
0 logzilla with trays 5-8 i will have 141 data disks , 35 spares , 16 logzilla
0 logzilla with trays 9-12 i will have 218 data disks , 54 spares , 16 logzilla
best case performance disk/ssd ratio
for 2 pools is 32/8 , 70/8 and 109/8
for 4 pools is 16/4 , 35/4 and 54/4
for 16 pools is 4/1 , 9/1 and 14/1
This is only theoretical because after 8 jbods you have to add another sas hba
so instead of having two column of 6 trays you have three column of 4 trays.
Question is where i should put the fourth jbod with SSD ?
My personal answer is better to avoid configuration that will grow up with more
than 8 jbods for now if looking for performace . In the future we will see ...
Last edited by user469; 26th June 2010 at 12:16 AM.
give me a call to talk this through. I've got some capacity calculations on the S7000 JBODs that might prove interesting for you.
what i'm trying to figure out how performance will wary with a given number of LogZilla SSD using 1 to 4 jbod trays , or 5 to 8 trays , or 9 to 12 trays , because i will add more disks but SSD will remaing the same because of the limitation .
It all really depends on the workload on the box. I always recommend that customers invest in at least 2 x LogZillas as a minimum and then as their storage and IOPS requirements grow then more disk and SSDs can be added later.
If you're looking at 16 x LogZilla SSDs then you must have a massive random write IOPS requirement and maybe we need to talk in more detail about your specific needs.
This is exactly the best practice to follow , start with a tray with 2 x LogZillas and then add same type of tray up to the fourth tray.It all really depends on the workload on the box. I always recommend that customers invest in at least 2 x LogZillas as a minimum and
then as their storage and IOPS requirements grow then more disk and SSDs can be added later.
I would recomend 1 x LogZillas every 11 disks .
If someone needs massive IOPS its better to start with a tray with 4 x LogZillas and then add same type of tray up to the fourth tray.If you're looking at 16 x LogZilla SSDs then you must have a massive random write IOPS requirement and maybe we need to talk in more
detail about your specific needs.
Who are you and who do you work for?
i do work for an ITSP and i am a technical designer specialist , 30 year experience in the
computer field , modem and router , lan , wan , server , voip and storage .
This update causes our 7310 to hang with no network access or web console, have had to roll back to previous version. Will be on to Oracle in the morning to look into it, worked fine on a 7110. Very strange.
Aww, don't say that, I was planning to put it on our 7410 this Friday because of a bug with the latest 2009 Q3 release that caused the same issue! Turned out (we think) to be a bug with how many logs AKD can process when it starts up. We had quite a few log files for some reason, AKD hung without starting cleanly which means no shares, network, BUI, etc. An awesome guy at Sun support talked me through a console rollback and it started up okay, then he manually cleaned up some logs. Apparently this bug was fixed in the 2010 releases though...
This is on the 2010 release, going from 2010.Q1.1.0 to 2010.Q1.2.0. It's strange, our 7310 quite often has issues updating, the 7110's always work perfectly.
There are currently 1 users browsing this thread. (0 members and 1 guests)