toasters March 1999

toasters@lists.teaparty.net

138 participants
192 discussions

NVRAM PCI cards
by Daniel Quinlan 23 Mar '99

23 Mar '99

Does anyone know who makes the NVRAM cards used by NetApp (for F630 and earlier)? No, I'm not looking to put this into one of my NetApps, but I am looking for a PCI card with some sort of non-volatile RAM that I can purchase. Ideally, some sort of battery-backed RAM -- not flash. - Dan

5 4

Re: NVRAM PCI cards
by mds＠gbnet.net 23 Mar '99

23 Mar '99

You could always give solid state disk a try - fibre channel or SCSI connection and capacities from jsut over a hundred MB to about 17GB are available. A 17GB battery backed solid state RAM drive would cost about 250,000 USD though.. 8)

1 0

RE: NVRAM PCI cards
by Packer, Gary 23 Mar '99

23 Mar '99

I believe the NVRAM card used in the EISA system was designed by a company called PEP, I don't know if they offer a PCI version. Since the F330 series, we have used our own proprietary design of NVRAM. -----Original Message----- From: guy(a)netapp.com [mailto:guy@netapp.com] Sent: Monday, March 22, 1999 7:02 PM To: quinlan(a)transmeta.com Cc: toasters(a)mathworks.com Subject: Re: NVRAM PCI cards > Does anyone know who makes the NVRAM cards used by NetApp (for F630 > and earlier)? Network Appliance, Inc.. (Well, they're probably actually *manufactured* by Solectron or some other contract manufacturer, but they're *not* an off-the-shelf part we buy from somebody else.) The NVRAM card used on the EISA filers came, as I was told, from a company that had an ISA NVRAM card - we had them design an EISA version. If they're still around, they may have a PCI card; I don't remember the name of the company, but I can ask around....

1 0

Re: NetApp/Auspex killer?
by Arvind K Aggarwal 23 Mar '99

23 Mar '99

> > > It all boils down to the words "disaster" and "recovery" being > > subjective.... > > > > And the "official" meanings change between the time you show > > management a price tag and when the data center catches on fire. :) > > > > > > jason > --- > > *laugh* > > Good one! > Until the data center catches fire and the same folks wanna know why *YOU* did not tell them the whole truth. I agree with jason, I just like to put in every caveat possible to cma. Arvind

1 0

RE: NetApp/Auspex killer?
by Mohler, Jeff 23 Mar '99

23 Mar '99

> It all boils down to the words "disaster" and "recovery" being > subjective.... > > And the "official" meanings change between the time you show > management a price tag and when the data center catches on fire. :) > > > jason --- *laugh* Good one!

1 0

RE: NetApp/Auspex killer?
by Mohler, Jeff 23 Mar '99

23 Mar '99

In our carrier atmosphere, we'll purchase our way around the performance hit. Instant, constant mirroring is our only option for the various network operations we perform. > -----Original Message----- > From: tkaczma(a)gryf.net [SMTP:tkaczma@gryf.net] > Sent: Monday, March 22, 1999 6:47 PM > To: toasters(a)mathworks.com > Subject: RE: NetApp/Auspex killer? > > > > On Mon, 22 Mar 1999, Mohler, Jeff wrote: > > > Your DR solution should PUSH data out constantly, not request it > > remotely every 60 seconds, then if a snapcopy fails for that period, it > gets > > thrown away on the remote side...two lost minutes of data. > > That's true for your application, but I don't want to mirror my disks > across the country even every 60 seconds. Once every couple of minutes > or hours is perfect for me. If you truly mirror your disks the latency > associated with data propagation will kill the performance. > > Tom

1 0

RE: NetApp/Auspex killer?
by Mohler, Jeff 23 Mar '99

23 Mar '99

> -----Original Message----- > From: Thompson, Arnold [SMTP:arnold.thompson@netapp.com] > Sent: Monday, March 22, 1999 1:04 PM > To: Mohler, Jeff; toasters(a)mathworks.com > Subject: RE: NetApp/Auspex killer? > > You're gonna *love* SnapMirror & SnapRestore! --- Already seen it, it does -not- match up to what EMC can do for us for remote DR service. A possible 2 minute outage in data-flow is a literal million dollar question for us. Your DR solution should PUSH data out constantly, not request it remotely every 60 seconds, then if a snapcopy fails for that period, it gets thrown away on the remote side...two lost minutes of data. Thats is at a minimum FOUR lost billing cycles on our ATM/IP/Voice network...and in our environment an incomplete billing cycle is non-billable. I belive the continuous real-time transfer of data from the main site to the remote site would be a solution that we could live with in the future.

3 2

RE: NetApp/Auspex killer?
by Thompson, Arnold 22 Mar '99

22 Mar '99

Management says I can't tell you right now or they'll have to kill us both! We will be making an official announcement shortly, when it's available. > -----Original Message----- > From: Jason D. Kelleher [mailto:kelleher@susq.com] > Sent: Monday, March 22, 1999 12:18 PM > To: Thompson, Arnold > Cc: toasters(a)mathworks.com > Subject: Re: NetApp/Auspex killer? > > > In message > <7F608EC0BDE6D111B53A00805FA7F7DAF0C14A(a)TAHOE.netapp.com>, "Thomp > son, Arnold" writes: > >You're gonna *love* SnapMirror & SnapRestore! > > Hmmm... SnapRestore...? > > If this does what it sounds like it does, tell me more! If it > means no more waiting while several GBs are tar'd out of > a snapshot > and re-written to a "real directory" after a developer said > "Oops..", tell me how much! Actually, free would be > prefered... :) > > The only reference I could find to "SnapRestore" on NOW was on the > "Copyright Information" page, so let's hear it! > > jason > > >

1 0

Re: NetApp/Auspex killer?
by Jason D. Kelleher 22 Mar '99

22 Mar '99

In message <7F608EC0BDE6D111B53A00805FA7F7DAF0C14A(a)TAHOE.netapp.com>, "Thomp son, Arnold" writes: >You're gonna *love* SnapMirror & SnapRestore! Hmmm... SnapRestore...? If this does what it sounds like it does, tell me more! If it means no more waiting while several GBs are tar'd out of a snapshot and re-written to a "real directory" after a developer said "Oops..", tell me how much! Actually, free would be prefered... :) The only reference I could find to "SnapRestore" on NOW was on the "Copyright Information" page, so let's hear it! jason

1 0

Re: Quad Ethernet
by Rob Windsor 22 Mar '99

22 Mar '99

On Fri, 19 Mar 1999 14:55:46 EST, Paul Taylor wrote: > I am installing quad fast ethernet cards in my F330 and F630 filers. > 1) What version of ON-TAP should the filers be running? > 2) What configurations issues should I be aware of, and how are > multipule default gateways configured? Assuming that you are running a quad card so that you can touch four different subnets... We ran with a quad card in our F520 with 4.something (I forget now, we're currently at 5.2.1) for a year w/o any problems with that. You only have one "default gateway". Let's see if I can sum up why without oversimplifying: The kernel maintains a list ("routing table") of 'what goes where' when a packet has to go out. It would be prohibitively expensive memorywise to know the exact path ("route") that each packet had to take for each arbitary machine in your machine's IP world (usually the internet so that your autosupport mail makes it to netapp.com). To simplify things (and allow failover routing to function), the routing table only keeps a list of immediate networks and destinations (and hand-entered routes), and one place to send "everything else" that it doesn't know directly. This is the "default gateway". ok, sorry for the "TCP/IP Networking 101" class, but I thought it would help. With that in mind, things are very simple. If you already have a "default gateway" set up because of your single card, you probably don't have to change it. Just assign ip addresses for each of the ports on the quad card that you're going to use, wire them up, and boot (OS rev issues aside). fwiw, we tried to 'load balance' two ports by giving them different ip addresses on the same subnet and letting solaris automounter on each of the client boxes "choose the shortest path". It didn't work out as well as we had hoped, we're not hitting near 25% capacity on either of the two ports (mmm, mrtg). -- Rob ---------------------------------------- Rob Windsor E-Mail - mailto:windsor@adc.com Senior Unix Systems Administrator Voice - phone:972-680-6919 Computer Services Fax - phone:972-680-0370 Business Broadband Group ADC Telecommunications Richardson, TX 75082

3 2

← Newer
1
2
3
4
5
6
7
8
...
20
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters March 1999