Re: How to do disk slicing on Sun stroEdge A3500 Boxes

SINGLE E10000 with 7 A3500 storage array which has 14 internal controller and 24 GB RAM over 6 coserver. Every A3500 has 2 internal controller. Also it has 7 * 5 (5 disk tray of 7 disks i.e. 7 luns of 5 disk each). Every lun is of 35 GB size but i have only 17 (2 GB slices), rest of the space is for file systems. My problem is that how can I allocate for e.g. one month of data on 6 coserver over all the 14 controller, on all the boxes and across the luns. Sanjeev K. Sagar --- Tim Schaefer <tschaefe@bellsouth.net> wrote: > Sanjeev, > > I'm confused but that's not hard to do. :-) > > Please tell me, how many physical computers are in > the cluster: > Do you have 6 Sun E10000 computers or one > computer??? > > It would be a major expenditure if you have six of > these > machines, but hey, somebody is really spending some > serious > money here. > > In my limited experience I would be more concerned > about the > layout of the data to avoid data skew. You have a > good number > of coservers to help accomplish this the key is > setting up a > spreadsheet of your disks with each month rotating > across your > coservers. Odd-numbers of coservers give you the > greater > possibility of data skew especially with month-based > fact tables, > because as you lay out the months across the > coservers you will > end up with odd-ball layouts. For example, your > 6-coserver setup > should give you two months per coserver. If you had > an odd number > of coservers, the distribution gets lopsided. > > If you load balance your data correctly according to > XPS design > the only other thing left to do is test it and see > how it performs. > And at this point I'd definitely get Informix ATG in > on the testing > and let them give you the inside track on what to > do. They hear > the latest on what people are doing and pass it on. > > Hope this helps, > > Tim > > sanjeev sagar wrote: > > > > Hi everyone, > > > > H/W : Sun E10000 > > Ifmx : XPS 821.UD4 [ 6 coserver environment] > > O/S : Solaris 2.5.1 > > > > Machine configuration : > > > > Sun E10000 with 7 Sun StorEdge A3500. All 7 A3500 > has 14 internal > > controller, 2 internal controller per A3500. Every > A3500 has 5 disk > > tray of 7 physical disk of 9 GB each. So every > A3500 has 7*5 i.e. 7 > > luns of 5 disk each. Every lun has 5 (9 GB each) > disk. Every lun has 17 > > (2 GB slices), rest of the space is for file > systems. > > > > Since every A3500 has 2 internal controller, so > every lun is on > > different controller like if controller are c1, c3 > then lun allocation > > will be > > > > l1 will be on c1, l2 will be on c2, l3 will be on > c1 and so on ....l7 > > will be on c1. > > > > Problem : > > > > I have 6 coserver environment. I need to load a > fact table of 14 month > > of data. so far I am able to calculate that every > month will be having > > 18 (2 GB slices i.e. 3 layers of 2 Gb slices all > over the 6 coserver). > > The problem is > > > > HOW TO ALLOCATE ALL 2 GB SLICES OVER DIFFERENT > CONTROLLER, DIFFERENT > > LUNS AND OVER DIFFERENT BOXES. > > > > I have 4 main fact table. I am looking for some > logic where i can come > > out with the kind of name like > > > > b-box, l-lun, s-slice > > > > if i see b01l00s01-> this kind of nomenclature can > tell me that which > > controller my slice is b'coz every lun will be on > different controller. > > > > I am sorry if any one find it confusing but the > fact is this is > > confusing. What i am trying to achieve is to use > all the controller on > > all luns on all boxes, in order to avoid any I/O > contentions for all > > fact tables. My fact tables will be fragmented on > the basis of month. > > > > Also, i read many times that RAID5 strip block > size should be 8*page > > size i.e. for xps it will be 32K. > > > > CAN SOME ONE TELL ME WHERE ICAN FIND SOMTHING LIKE > THIS MENTIONED IN > > INFORMIX TECH OR SOME DOCUMENTATION where i can > show to my mangers that > > this is documented OR ANY BENCHMARK SETUP. My team > lead are not > > beleiving this. They think 8 K is the perfect > size. I guess some 'O' > > dba might have told them Oracle work better with > 8K, so they think the > > perfect strip size for all the DBMS is 8K. > > > > I guess that i tried to explain my problem the > best i can. Excuse me if > > it is not explained in simple way. > > > > Thanks > > > > > > __________________________________________________ > > Do You Yahoo!? > > Bid and sell for free at http://auctions.yahoo.com > > -- > . > .- > .-- > .--- > .---- Tim Schaefer > .----- tschaefe@bellsouth.net > .---- http://www.inxutil.com > .--- http://www.datad.com > .-- > .- > . > __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com

sanjeev sagar wrote: > > SINGLE E10000 with 7 A3500 storage array which has 14 internal > controller and 24 GB RAM over 6 coserver. In other words have you divided the E10000 into six separate CPU Domains treating each as a separate virtual machine with one XPS coserver running on each? Or is the machine a single domain with six co-resident coservers on it? > Every A3500 has 2 internal controller. Also it has 7 * 5 (5 disk tray > of 7 disks i.e. 7 luns of 5 disk each). Every lun is of 35 GB size but > i have only 17 (2 GB slices), rest of the space is for file systems. > > My problem is that how can I allocate for e.g. one month of data on 6 > coserver over all the 14 controller, on all the boxes and across the > luns. I'd get a Sun engineer in on this one. It is giving me a headache. > Sanjeev K. Sagar > > --- Tim Schaefer <tschaefe@bellsouth.net> wrote: > > Sanjeev, > > > > I'm confused but that's not hard to do. :-) > > > > Please tell me, how many physical computers are in > > the cluster: > > Do you have 6 Sun E10000 computers or one > > computer??? > > > > It would be a major expenditure if you have six of > > these > > machines, but hey, somebody is really spending some > > serious > > money here. > > > > In my limited experience I would be more concerned > > about the > > layout of the data to avoid data skew. You have a > > good number > > of coservers to help accomplish this the key is > > setting up a > > spreadsheet of your disks with each month rotating > > across your > > coservers. Odd-numbers of coservers give you the > > greater > > possibility of data skew especially with month-based > > fact tables, > > because as you lay out the months across the > > coservers you will > > end up with odd-ball layouts. For example, your > > 6-coserver setup > > should give you two months per coserver. If you had > > an odd number > > of coservers, the distribution gets lopsided. > > > > If you load balance your data correctly according to > > XPS design > > the only other thing left to do is test it and see > > how it performs. > > And at this point I'd definitely get Informix ATG in > > on the testing > > and let them give you the inside track on what to > > do. They hear > > the latest on what people are doing and pass it on. > > > > Hope this helps, > > > > Tim > > > > sanjeev sagar wrote: > > > > > > Hi everyone, > > > > > > H/W : Sun E10000 > > > Ifmx : XPS 821.UD4 [ 6 coserver environment] > > > O/S : Solaris 2.5.1 > > > > > > Machine configuration : > > > > > > Sun E10000 with 7 Sun StorEdge A3500. All 7 A3500 > > has 14 internal > > > controller, 2 internal controller per A3500. Every > > A3500 has 5 disk > > > tray of 7 physical disk of 9 GB each. So every > > A3500 has 7*5 i.e. 7 > > > luns of 5 disk each. Every lun has 5 (9 GB each) > > disk. Every lun has 17 > > > (2 GB slices), rest of the space is for file > > systems. > > > > > > Since every A3500 has 2 internal controller, so > > every lun is on > > > different controller like if controller are c1, c3 > > then lun allocation > > > will be > > > > > > l1 will be on c1, l2 will be on c2, l3 will be on > > c1 and so on ....l7 > > > will be on c1. > > > > > > Problem : > > > > > > I have 6 coserver environment. I need to load a > > fact table of 14 month > > > of data. so far I am able to calculate that every > > month will be having > > > 18 (2 GB slices i.e. 3 layers of 2 Gb slices all > > over the 6 coserver). > > > The problem is > > > > > > HOW TO ALLOCATE ALL 2 GB SLICES OVER DIFFERENT > > CONTROLLER, DIFFERENT > > > LUNS AND OVER DIFFERENT BOXES. > > > > > > I have 4 main fact table. I am looking for some > > logic where i can come > > > out with the kind of name like > > > > > > b-box, l-lun, s-slice > > > > > > if i see b01l00s01-> this kind of nomenclature can > > tell me that which > > > controller my slice is b'coz every lun will be on > > different controller. > > > > > > I am sorry if any one find it confusing but the > > fact is this is > > > confusing. What i am trying to achieve is to use > > all the controller on > > > all luns on all boxes, in order to avoid any I/O > > contentions for all > > > fact tables. My fact tables will be fragmented on > > the basis of month. > > > > > > Also, i read many times that RAID5 strip block > > size should be 8*page > > > size i.e. for xps it will be 32K. > > > > > > CAN SOME ONE TELL ME WHERE ICAN FIND SOMTHING LIKE > > THIS MENTIONED IN > > > INFORMIX TECH OR SOME DOCUMENTATION where i can > > show to my mangers that > > > this is documented OR ANY BENCHMARK SETUP. My team > > lead are not > > > beleiving this. They think 8 K is the perfect > > size. I guess some 'O' > > > dba might have told them Oracle work better with > > 8K, so they think the > > > perfect strip size for all the DBMS is 8K. The 8 page recommendation for stripe sizes stems from the fact the Informix performs either single page I/O or 8 page BIGWRITE I/O. Since the engine tries as much as possible to perform the more efficient BIGWRITES a stripe size of 8 * pagesize means the engine is normally writing an entire stripe in a single I/O request. Of course with a good disk farm, like the StorageEdge, with good intelligent caching the loss due to other stripe sizes is less of a problem than in the general case, but still a good idea. Art S. Kagel > > > I guess that i tried to explain my problem the > > best i can. Excuse me if > > > it is not explained in simple way. > > > > > > Thanks > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Bid and sell for free at http://auctions.yahoo.com > > > > -- > > . > > .- > > .-- > > .--- > > .---- Tim Schaefer > > .----- tschaefe@bellsouth.net > > .---- http://www.inxutil.com > > .--- http://www.datad.com > > .-- > > .- > > . > > > > __________________________________________________ > Do You Yahoo!? > Bid and sell for free at http://auctions.yahoo.com