|
Home > Archive > Data Storage > September 2005 > HP acquires Appiq
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
|
| boatgeek 2005-09-21, 5:48 pm |
| btw, does anyone really think HP wanted to do this? they had just
gotten out of the storage management business, got rid of their
developers and then they are suddenly getting back in? No, they got
in because they learned the hardware they had put all of their eggs in
the wrong basket and now need to go in personally and fix things.
This is an example of provisioning through appiq vs the clariion.
>From Clariion using Navisphere.
To create 5 4way meta luns you first create 20 luns. Within
Navisphere is takes probably around a two or three minutes for all of
them. You then expand 5 of the luns which would take around 2 minutes.
Then add the host to the storage group. That takes about a minute.
So around 7 or 8 minutes.
>From Appiq:
First you navigate to the clariion through appiq and then find the
appropriate volumes and mark from each which parts you wish to free up
as free extents, this should take around 3 - 5 minutes.
Then you go into the provisioning screen and select the type of
provisioning you are going to do, and select the SAN, then you select
the appropriate volume and select the free extent which will comprise
the first LUN. You then create the process and execute it. This will
take around 2-3 minutes if everything goes perfectly and perhaps
another minute for it to register.
Then you may need to wait for a topology build within appiq to
complete.
Then you go in and repeat this 20 times for your LUNs. 20 x 3 minutes
for 60 minutes.
You then go in and need to create you metas, each should take around
2-3 minutes a piece for the provisioning to complete and execute. BTW,
I'm being extremely optimistic regarding these times, it could take
much, much longer, but I'm assuming it will be blindingly fast and
stable compared to the older version. 5 jobs total, around 15 minutes.
After you've created the metas, you then need to assign the metas to
the appropriate server, each path for each LUN being a separate job, so
10 separate jobs. Each if it works perfectly taking 2-3 minutes
So 20 jobs for the LUNs, 5 jobs for the Metas and 10 jobs for assigning
it to the appropriate server for a total of 35 jobs. This could take
anywhere from 70 minutes to several hours depending on efficiency of
the operation and if it bombs out the interface (I've had the interface
bomb out several times trying to make just one job, but I'm assuming
the best).
| |
| Faeandar 2005-09-21, 5:48 pm |
| On 21 Sep 2005 14:33:59 -0700, "boatgeek" <dougvibbert@yahoo.com>
wrote:
>btw, does anyone really think HP wanted to do this? they had just
>gotten out of the storage management business, got rid of their
>developers and then they are suddenly getting back in? No, they got
>in because they learned the hardware they had put all of their eggs in
>the wrong basket and now need to go in personally and fix things.
>
>This is an example of provisioning through appiq vs the clariion.
>
>
>To create 5 4way meta luns you first create 20 luns. Within
>Navisphere is takes probably around a two or three minutes for all of
>them. You then expand 5 of the luns which would take around 2 minutes.
> Then add the host to the storage group. That takes about a minute.
>So around 7 or 8 minutes.
>
>
>First you navigate to the clariion through appiq and then find the
>appropriate volumes and mark from each which parts you wish to free up
>as free extents, this should take around 3 - 5 minutes.
>
>Then you go into the provisioning screen and select the type of
>provisioning you are going to do, and select the SAN, then you select
>the appropriate volume and select the free extent which will comprise
>the first LUN. You then create the process and execute it. This will
>take around 2-3 minutes if everything goes perfectly and perhaps
>another minute for it to register.
>
>Then you may need to wait for a topology build within appiq to
>complete.
>
>Then you go in and repeat this 20 times for your LUNs. 20 x 3 minutes
>for 60 minutes.
>
>You then go in and need to create you metas, each should take around
>2-3 minutes a piece for the provisioning to complete and execute. BTW,
>I'm being extremely optimistic regarding these times, it could take
>much, much longer, but I'm assuming it will be blindingly fast and
>stable compared to the older version. 5 jobs total, around 15 minutes.
>
>After you've created the metas, you then need to assign the metas to
>the appropriate server, each path for each LUN being a separate job, so
>10 separate jobs. Each if it works perfectly taking 2-3 minutes
>
>So 20 jobs for the LUNs, 5 jobs for the Metas and 10 jobs for assigning
>it to the appropriate server for a total of 35 jobs. This could take
>anywhere from 70 minutes to several hours depending on efficiency of
>the operation and if it bombs out the interface (I've had the interface
>bomb out several times trying to make just one job, but I'm assuming
>the best).
My guess is it's because HDS had an exclusive OEM agreement with AppIQ
and HP resells HDS so....
Probably not the only reason but a good one none the less.
Also, I assume what you're describing is based on no workflow being
present. As I understand it, the purpose of software like this is not
to make the manual processes faster, but to automate the manual
processes.
~F
| |
| Spindle 2005-09-22, 2:47 am |
|
boatgeek wrote:
> btw, does anyone really think HP wanted to do this?
I do. Can't think of a single reason why HP or anyone else would buy a
company without actually wanting to ?
> they had just
> gotten out of the storage management business, got rid of their
> developers and then they are suddenly getting back in? No, they got
> in because they learned the hardware they had put all of their eggs in
> the wrong basket and now need to go in personally and fix things.
>
Well, no offense, but it's a surreal explanation. Perhaps they got rid
of the old applications because they had no other choice.
HP probably took over to steer storage management where it's more
convenient or more strategic for them.
| |
| boatgeek 2005-09-23, 5:48 pm |
| You'd really have to use the product's provisioning to see why it is so
inefficient. Yes, the theory is that you simply select the SAN, then
the volume and free space, then the server and then it will allow you
to create a lun. But you are only creating a single lun. and to
create that job, you've just spent a lot of time (just to wait for it
to pull up the available volumes after you've selected the SAN takes
about 3 minutes). To create 20 of them, you need to repeat this
process 20 times. To create metas, you first have to create the luns,
then you go again and select the san, the server, and the volumes.
Finally to assign it to the server you need to select the san the
server and then the path to the server, once for each of the paths.
That's the problem, you literally spend more time creating these
'automatic' jobs then you would have spent (by a factor of 10 to 20
times as much time) doing it with the native tools. And it's no easier
than with the native tools. Clariion for instance you would simple
create the luns (you can do one in about 5 seconds), then expand the
luns and then assign it to a storage group with the host. You don't
need to tell navisphere (clariion) that it's multipathed and which
paths to assign the storage to.
| |
| boatgeek 2005-09-23, 5:48 pm |
| I agree that HP took over to steer storage management where it was more
convenient for them. What I do know though is that their rollout plan
for replacing their existing OVSAN customers stalled out and stopped
because they were having so many problems with the program. The dates
were scheduled for June, then just stopped. HP realized that for
appiq to replace their existing customer software, it needed many more
developers, more customer service and more reliability. They needed
more developers to write the patches necessary to stabilize the
product, more customer service people to handle 24/7 calls, and the
product needed more reliability because existing customers were having
4 or 5 call backs of FS engineers just to get the product working. I
also know that the existing appiq customers were threatening appiq by
suing for their money back unless the product stabilized. HP really
had no choice. They'd picked appiq, gotten rid of their own product
and then watched appiq start to stumble. When you pick a strategic
position, such as choosing appiq as your SRM, you wed your success to
theirs. If they start to not succeed, you have to do whatever it
takes to correct the situation.
|
|
|
|
|