Re: 306GB drives!

From: Rob Young (young_r_at_encompasserve.org)
Date: 08/17/03 

Date: 16 Aug 2003 17:27:18 -0500

In article <_Nu%a.93731$o27.2153066@twister.rdc-kc.rr.com>, "Mike Naime" <mnaime@kc.rr.com> writes:
>
> Rob Young <young_r@encompasserve.org> wrote in message
> news:Xrz7BErQmnjo@eisner.encompasserve.org...
>> In article <%lj%a.93485$o27.2125405@twister.rdc-kc.rr.com>, "Mike Naime"
> <mnaime@kc.rr.com> writes:
>
>> But you certainly could do a cheaper solution for backups
>> (if new) since you have existing infrastructure it makes
>> a lot of sense for you to pop in bigger drives.
>>
>
> Cheaper, yes. No argument there. But cheaper usually is inversely
> proportional to faster! After a test restore from tape. (The cheaper
> solution) Upper management let my director buy more storage for online
> backups. Restoring from tape is a 3rd or 4th option.
>

        I wasn't talking about tape. A cheaper disk based way would
        be to use ATA. For instance, Nexsan ATA is about 1.7 cents/MByte.
        You can get adventurous and get cheaper than that. But at 1.7
        cents that is $2 or so a GByte, you won't be buying HSG drives
        that cheap any time soon.

http://www.fusiondm.net/pages/ataboy.htm

> If I can have twice the storage space in the same spindle count, I can
> potentially have more backup copies online. The problem being in convincing
> my mangers to spend todays money on the larger drives. Plus, what do you
> do with all of those smaller spindles that you removed?

        Put them on the aftermarket - they will be bought from you
        pennies on the dollar.

>
>>
>> But you wouldn't want to use that larger storage here, right?
>>
>
> Personaly, no I would not WANT to use it here. But when your manager
> dictates what layout you are using for each client....you do what you
> manager wants.
>
> We tend to use the larger drives for non-prod systems where performance and
> uptime are not guaranteed, and not an issue. We have started to use 72GB
> drives for DB drives without seeing any performance problems.
>

        And EVA will mask the larger drives and performance issues.

> Also, what are you going to do in 10 years when you cannot buy anything new
> that is smaller than a Terrabyte? Historically we have been increasing hard
> drive technology by a factor of 10 about every 2-3 years. I started about
> 20 years ago on a 10 meg PC hard drive. Now we see 250 GIG drives available
> in the store, that is a 25,000 times increase in drive size. This translates
> to about 16 generations in 20 years if we use the doubleing of the drive
> size to represent a generation in a geometric progression. Also note that a
> 40 GIG drive is the smallest drive that they are selling today.
>
> Let's project this into the future and be conservative for arguments sake.
> If a drive doubles in size every 2 years, and we now have 300GB disks. (Nice
> round number) in 10 years we will have 9.6TB drives. And the
> manufacturers/vendors will probably not be make anything less than a 1.2TB
> drive from 3 generations back.
>

        I'm pretty sure this is something that won't extend out. We will
        see a flattening in drive sizes in a bit. After that, surely
        we cutover to some of this Oak Ridge technology:

http://www.acq.osd.mil/bmdo/bmdolink/pdf/roo.pdf

Oak Ridge National Laboratory (Oak Ridge, TN)

A new technique developed at Oak Ridge National Laboratory offers an answer to
the demand for increased storage density. Surface-enhanced Raman optical data
storage is based on a technology that detects the optical signature of
laser-excited molecules. This data storage method involves the alteration of
molecules that are embedded in a polymeric or silver- colored disk. A laser
is used to "write" information on a disk, on which the optically altered
molecules and unaltered molecules serve as "bits." The normally weak Raman
signature of each molecule is amplified or enhanced by the substrate of the
storage disk, such that the signature can be read by a signal detector.

        Or something simalarly whizbangy.

        You see a flattening today - even if only in home PC markets.
        In the future it may make little or no sense to get super large
        sizes as even with partitioning you end up with catastrophic
        effects if you blow out a RAIDset and other issues that I'm sure
        folks have in mind.
>
>>
>> I don't use any local drives in my cluster.
>
> Great! Ever done a hardware move?
>
> Example. Alphaserver X freezes solid for no apparent reason (Turns out to
> be memory dimms), Or is bugchecking repeatedly during system boot. You
> zone in a spare Alphaserver. Enable the storage. Patch the network
> cabling, and boot up on the new server. About 1 hours work without prep
> time. If I have time to prep the move, it is a Shutdown, Patch network, and
> Boot the new system. This way I can troubleshoot hardware problems on my
> time instead of the clients time.
>

        I think the PRIMARY purpose of a cluster is for availability. You lose
        a member , you replace it. You can replace it in an hour or
        so - great. I'm content to replace a member within a day. Going
        forward I would like to add a member and go to next day on service.
        If they had a "next week" service option, I'd take that too ;-).

> Except for physically having to patching the network cables, I can do all of
> the rest remotely.
>
>> >
>> > Personally, I think that shadowing is one of the biggest performance
> hits
>> > that you can take on a VMS system.
>>
>> Not really. A large OEM of storage would try to convince you
>> of such a farce. But when pressed for any data at all to
>> back up their FUD - they slink away.
>>
>> Think about it - if you have a storage back-end with
>> write caching enabled - where does the "Volume shadowing overhead"
>> come in?
>>
>
> When a cluster member crashes and the resulting shadow copies make the
> responce time unacceptable to the end users for several hours.
> I did not setup that system, and cannot comment on how it is setup. I just
> know that I do not have that particular problem on my systems.
>

        Right. Full merge during primetime can be a killer. That is a
        non-HSJ weakness - soon to be remedied. The last criticism of
        Shadowing becomes a non-issue with host-based mini-merge coming
        to a cluster near you.

>> And at that - yes there are folks that it is a performance
>> issue - a pathalogical case perhaps? 60% write traffic and
>> tons of it? What if like many you do a normal 15% (or so) write rate?
>> Question that a FUDster can't really deal with and quickly changes
>> the subject (not you - my actual experience).
>>
>
> I'm not really taking issue with the normal routine performance of the
> system. I'm more looking at the break-fix, and downtimes associated with
> this. This is what get rolled into OUTAGE or DOWNTIME that we can be
> penalized for.
>

        Hmmm - okay.

>> > The EVA really is making it potentially possible to do away with
> shadowing.
>> > You do your backups and redundancy at the disk controller level. Not at
> the
>> > OS level.
>>
>> Nah. You have two or more EVAs and shadow across datacenters. That
>> way when your datacenter loses power you keep going.
>
> Yes, but my point is that it would not be possible without the EVA.
> EVA's in 2 data centers does not necessarily need to be made redundant by
> host based shadowing.

        With VMS - sure. VMS doesn't support DRM 2 and/or DRM 2 isn't
        here yet. To make it more generic - have 2 separate storage
        "boxes" in 2 separate data centers. Now you use HBVS across
        datacenters.

> The solution is preferred if I can take the OS out of the picture.
> Otherwise, I will have 150+ systems trying to write to the far end.

        The far end doesn't have to be that far away. I'm not speaking
        of DR but fault tolerant.

>>
>> > Tape is TOO SLOW for restores!
>>
>> LTOs are pretty fast - but yes disk can be faster and a great
>> argument for. One of the greatest arguments for (we are learning)
>> is mail restores. The problem is files are across many tapes. You
>> can run TSM consolidations to help. This is a case where full
>> images all the time are a big win, but often not realistic.
>>
>
> Why not??? Follow your own argument here. If downtime potentially costs
> management millions of dollars, and they are choking on the $$$ for the
> solution. That is their decision to make, but the downtime would probably
> cost them more than the solution. The problem for them is that it comes out
> of todays budgetary dollars rather than tomorrows lost revenue.
>

        Mail is the key. Mail proliferates like rabbits. Unfortunately,
        it is mostly flat files on disk. Files that are old and make
        little sense to back up over and over again. Unfortunately, scattered
        on many tapes so restores are long. However, mail is very distributed
        and a small subset are impacted if a server is down. This isn't
        everybody in the world. Sure, consolidate your tapes OR go to
        large ATA storage pool for D2D.

>>
>> I would make them fully understand how long you will be down
>> when you blow out a RAID5 and have to restore. In fact, a test
>> restore might convince them you need to go in a different direction.
>>
>
> Actually a test restore of an entire cluster convinced them that tape was
> too slow. My director called us in one day and told us that Client X's
> hardware is toasted. Nothing is usable. (I.E. Logging onto the running
> system to check something is not allowed here) Here is a set of backup
> tapes. The clock is ticking. Go restore this. This pulls in the question
> of exactly how good your documentation on everything in your setup is. How
> many copies of it you have, and where it is located..
>

        You mean [older] DLT is too slow? Surely you didn't have 2 or 3
        LTO tape drives actively doing the restore? We typically get
        20 MByte/sec to/from LTO. With 40 MByte/sec on restore - that's
        140 GByte/hour. That isn't VMS - but VMS plays well with
        3rd party Enterprise Backup solutions and will natively work
        with LTO 2 (faster yet) or so recent discussions have mentioned.

        What is your restore speed criteria? Surely met by LTO (assumption
        you would have 2 streaming your restores).

                                Rob

Relevant Pages

  • Re: 306GB drives!
    ... But cheaper usually is inversely ... > the demand for increased storage density. ... > molecules that are embedded in a polymeric or silver- colored disk. ... As the drives get bigger, ...
    (comp.os.vms)
  • Re: 306GB drives!
    ... > a lot of sense for you to pop in bigger drives. ... After a test restore from tape. ... Restoring from tape is a 3rd or 4th option. ... Also look at the cost per spindle for your storage. ...
    (comp.os.vms)
  • Re: How to increase hard drive space.
    ... recent restore points. ... > You should periodically defragment your hard drives as well as check them ... You should at least turn on the built in firewall. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Computer problem, need help
    ... defining the three levels of backup and recovery. ... has been corrupted, use backup and restore. ... hard drives and a reliable backup utility like Ghost. ...
    (soc.retirement)
  • Re: Sizing Exchange Transaction, SMTP, MTA and Quorum Drives???
    ... You are assuming .85 IOPS per user ... You're off the end of the tables in "Optimizing Storage for Exchange ... When calculating the write penalty for RAID 10, ... storage groups 4 drives). ...
    (microsoft.public.exchange.design)