Does anyone have some experience setting up an NT4/IIS 4.0 Web
server with the FrontPage extensions, using a Netapp as the data
store? According to Microsoft (and supported by our own tests),
FrontPage will *not* work to a network share. In fact, many Microsoft
server products will lose much of their functionality if they are not
run on local disks.
I'm pretty much convinced this is an NT issue and not a Netapp one
(since we can't get FrontPage to work even when sharing a filesystem
from …
[View More]another NT box). What are the alternatives? NFS on NT? We
asked a Microsoft IIS engineer how MS handles the problem of
distributed servers, and his response was "Oh, we just replicate all
our data". :-/
--
Brian Tao (BT300, taob(a)netcom.ca)
"Though this be madness, yet there is method in't"
[View Less]
> That's another approach we can take, but since IIS is the only
>Microsoft component left in the equation, Microsoft probably won't
>like that much (this hosting agreement is part of a larger deal
>between our two companies). ;-)
Brian,
I know of a few filer customers who are using IIS with the filers
using CIFS. No one is using the Frontpage 98 extensions to IIS, as they
don't work over a network share. As Mike Patchen pointed out, Microsoft
has promised to fix this in …
[View More]Frontpage 99. If this is really important
to you, you should bring that up as a requirement to Microsoft.
Andy Schulert <andyschu(a)microsoft.com> is the person to send your needs to.
The people successfully using IIS with filers are currently
using FTP - to allow users to upload web pages to their personal
directories. With the filers, we also have created a special
NT utility that "effectively" allows large # of directory quotas
for this special situation. This is so you can do quotas for your
web-hosting users. Using quotas on filers is apparently the only
scalable quota solution available for NT today (according to
people who use them). We can polish this utility for wider
usage, if we see a lot of demand for web-hosting quotas.
Regards,
-Rajiv
----
Rajiv Khemani
Group Marketing Manager
Network Appliance, Inc.
Direct: 408-367-3758
Fax: 408-367-3670
HTTP: http://www.netapp.com
[View Less]
On 03/12/98 23:39:54 you wrote:
>
>On Thu, 12 Mar 1998 sirbruce(a)ix.netcom.com wrote:
>>
>> The alternative is pretty clear to me... don't use IIS/FrontPage if
>> it requires you to redo your entire infrastructure or approach in
>> order to support it.
>
> I don't think that's an option, unfortunately. The challenge is
>to give customers what they need, rather than what they think they
>want. They want NT. What they need is an easy way to manage …
[View More]the
>content of their Web site and the e-mail of their employees, without
>having the first clue about the Internet.
I can sympathize. I'm sure everyone here does. We've ALL been there. :)
And I'm not trying to start that tired old UNIX vs. NT argument. There
are circumstances where NT is a fine solution. All I'm saying is that if
the application isn't up to your needs, perhaps one should consider a
different application. (And if that means a different platform, then you
have reason to question NT in the first place.)
>Writing our own software to
>do that would take a lot longer than buying an off-the-shelf product.
>Maybe we'll go with FrontPage with Apache on Solaris, or perhaps we'll
>find that NFS on NT with the Netapp does the job for us.
I wouldn't be surprised if IIS/FrontPage have the same troubles over NFS
on NT, but I confess I don't know for certain as I've never tried it.
Bruce
[View Less]
On 03/12/98 15:22:50 you wrote:
>
> Does anyone have some experience setting up an NT4/IIS 4.0 Web
>server with the FrontPage extensions, using a Netapp as the data
>store? According to Microsoft (and supported by our own tests),
>FrontPage will *not* work to a network share. In fact, many Microsoft
>server products will lose much of their functionality if they are not
>run on local disks.
>
> I'm pretty much convinced this is an NT issue and not a Netapp one
…
[View More]>(since we can't get FrontPage to work even when sharing a filesystem
>from another NT box). What are the alternatives? NFS on NT? We
>asked a Microsoft IIS engineer how MS handles the problem of
>distributed servers, and his response was "Oh, we just replicate all
>our data". :-/
The alternative is pretty clear to me... don't use IIS/FrontPage if it
requires you to redo your entire infrastructure or approach in order to
support it.
Bruce
[View Less]
Well, my migration of content between filers is complete and
I have a few odd tidbits I thought I would share.
- ndmpcopy is an interesting (but frustrating) program.
It is great to be able to kick off a dump piped to a restore
on a remote filer via ndmp. level0's work well. The time estimates
are pretty accurate (I got 30GB in 7 hours) if a bit slow. The
irritating aspect of it is that ndmpcopy "hangs" after the completion
of the program (at least when the source filer is 4.2a and …
[View More]the destination
filer is 4.3.1) and the /etc/dumpdates file is not updated. This makes
incrementals impossible.
- gnu find and cpio are your friend for incrementals. I did a level0 dump
(with ndmpcopy) 2 days before my cut-over. The night of the cut-over, I did
a find (with mtime -2) piped to cpio (-dump) onto the new location. It took
under 1/2 an hour to do most everything. Had I parallelized the finds a bit
more, it would have probably been around 15 minutes to complete.
Having completed the migration, here is what the before/after stats are:
before: f540/256MB ram/8MB NVRAM; 3000-4000 NFSops avg, 80-100% cpu util, 1 min cache
after:
f540/256MB ram/8MB NVRAM; 1500-2000 NFSops avg, l0-20% cpu util, 25 min cache
f630/512MB ram/16MB NVRAM; 1800-2200 NFSops avg, 20-30% cpu util, 27 min cache
The f540 contains tools, logs and home directories.
The f640 contains web content.
My users were immediately able to notice a significant speed improvement (we use alot of
server side includes which lead to alot of IO) when dealing with certain areas of
our websites.
I would like to thank Beepy (from NetApp) for helping me in this endeavor.
I hope might be of use to someone at some point.
Alexei
[View Less]
Hi ther everyone. I have a customer that *wants/needs* to use
NDMP.
I know for a fact that BudTool works. Has anyone else had
successful attempts with other packages? like Veritos?
or even OpenVision?
thanks!
--
Timothy A. McCarthy --> System Engineer, Eastern Region.
Network Appliance http://www.netapp.com
301-230-5840 Office \ / Page Me at:
301-230-5852 Fax \/ 800-654-9619
In Norway we agree with Mr. Alexei regarding support of the AIT
streamer from SONY or Seagate (called Sidewinder for Seagate) on the
filers.
It is correct that the DLT7000 (on the brochure) has the possibilities
of slightly more sustained transfer the the AIT, but in real life the
AIT slightly outperforms the DLT 7000 - and in addition the AIT's are
60% cheaper!
In Norway the pricing at the moment is approximately DLT7000 85000 NOK
and the AIT 35000 NOK.
Big shock people wanting the AIT'…
[View More]s.
The AIT's are using the most powerful compression algorithm in the
market (ALDC developed by IBM).
Compression ratio is in average 1:2.6, which gives in average approx.
65 GB on each media.
DLT's and Mammoth in average 1.8 (Mr Gremban, TI below is reporting
an average on appr. 1.7)
The sustained transfer is increasing to the same 1:2.6 ratio (7.8
MB/sec)
In addition the AIT has a Metal evaporation and Carbon coating on the
media which makes the media even more robust (archival time on media
guaranteed from SONY > 30 years)
Memory In Cassette (MIC) on the AIT makes the funniest difference:
Media Load Time 10 sec - DLT 45 sec. (4,5 times
faster)
Average File Access 23 sec - DLT 60/68 sec (3 times faster)
Regarding transfer rate, whether the AIT or the DLT7000 has any
problems recieving the data from the NetApp filers because of the
following:
Since most of the filers installed usually is containing thousands and
millions of small files instead of a few big files - this (whether one
likes it or not) leads to an significant decrease in backup
throughput. This happens not only on NetApp filers, but on all kinds
of machines serving files out there. The MB/min output number will
anyway be lower than the number handled by the AIT and DLT.
So AIT is 60% cheaper, has 3-5 times faster access/media load time and
arhival time in the media is more than 30 years. This is what is
interesting to the customer base. You could buy two AIT streamers
instead and place them both locally on the NetApp's - maybe this will
do something with the numbers, I am not sure.
By the way, AIT-2 is coming in the autumn this year. 130GB capacity
and transfer rate 12MB/s compressed.
Please support the AIT's!
Rgds
Asle Tronrud
_______________________________________________________
Asle Tronrud
Sales Engineer Storage
Berendsen Data Tel. +47 2208
8500
Div. av Berendsen Components AS Dir. +47 2208 8569
Konows gt. 8 Fax. +47 2208
8595
P.O.Box 9376, Groenland Mob. +47 9001 2906
N-0135 Oslo, Norway Email:
aslet(a)berendsen.no
http://www.berendsen.no
_______________________________________________________
-----Opprinnelig melding-----
Fra: Bjørnsen, Paal H. EDNO
Sendt: 13. februar 1998 09:19
Til: Tronrud, Asle EDNO
Emne: VS: AIT vs. DLT7000
-----Opprinnelig melding-----
Fra: Steve Gremban [SMTP:gremban@msp.sc.ti.com]
Sendt: 13. februar 1998 07:39
Til: toasters(a)mathworks.com
Emne: AIT vs. DLT7000
Alexei,
We are using DLT7000 (5-10 MB/sec depending on compression) drives
which
actually outperform the Sony AIT (3-7.8 MB/sec depending on
compression). We are
not quite seeing 2:1 compression, we get about 60GB compressed on each
35GB
tape.
-Steve Gremban gremban(a)ti.com
-----------------------------------------------------------------------
Previous message follows:
I would like to see AIT supported; we currently use DLT, but as our
backup
needs are approaching 300GB (well, as soon as I get my new filer),
DLT is not cutting it (backup/restore times are too long). Also, the
media
is a huge problem (DLT's are not all too happy with a drop...).
I suspect that these additional drives will be supported eventually.
Alexei
-----------------------------------------------------------------------
[View Less]