Re: sunsolve https not working?

Oracle Sunsolve appears to be down/unaccessible/incredibly slow...again.

Attempted to avoid this problem by pre-downloading patches in advance, but
apparently a new patch was released...after 5 attempts on HTTPS request 
using pca:

ERROR: 503 Service Unavailable.

Finally logged in on Sun website, but response time is incredibly slow...
Will attempt a manual download, eventually.

Same experience at Memorial Day weekend...
Anyone have any idea when Sunsolve will be fully back and what the 
issues are??

all info appreciated,
DM Orrick

On 6/28/2010 2:06 PM, Martin Paul wrote:
> Hi Don,
>
>> I just checked this out and all appears to be working fine for me; 
>> longest delay was about 7 seconds...
>
> The delays have gone down to a similar maximum here, so I guess it's 
> fine now.
>
> Thanks,
>
> Martin.

Re: sunsolve https not working?

Diana Orrick wrote:
> Oracle Sunsolve appears to be down/unaccessible/incredibly slow...again.

Yes, I've seen hangs this morning, too.

> Same experience at Memorial Day weekend...

Yes, it seems as it's mostly weekends when the problems show up - I've 
experienced download issues on the last three weekends/Mondays in a row. 
   Maybe the service is so sensitive that it needs daily care, which it 
doesn't get over weekends and holidays? Or the last one leaving the 
office on Friday turns off the SunSolve server?

> Anyone have any idea when Sunsolve will be fully back and what the 
> issues are??

No idea. But it's a shame for an IT company, not being able to provide a 
stable file download server. It also makes pca look unreliable, which I 
really don't like.

Martin.

Re: sunsolve https not working?

Re: sunsolve https not working?

Re: sunsolve https not working?

<snip>
>  No idea. But it's a shame for an IT company, not being able to provide a
> stable file download server. It also makes pca look unreliable, which I
> really don't like.
>
>  Martin.

pca works wonderfully.

We *know* where the breakage is and it isn't anything in Perl or pca on
production grade Solaris.

Someone should call up the product sales VP at Oracle and let them know
that the real users, the guys that live in front of these servers are the
systems admins and NOT the damn sales reps or the purchase agents and what
we see lately is one hell of a lot of "unreliable" Oracle services. We
sysadmins talk to each other ALL the time in places these salesreps and
VPs never see. If Oracle has a clue, even a foggy faint clue, they will
fix their little Sunsolve problem real quick or those purchase agents
won't be seeing RFQ's anymore. The purchase orders stop and then the
revenue stops and it was the sysadmins that put the brakes on .. not the
sales reps and not the purchase agents and not some middle manager on a
golf course that has never seen an "ok" prompt.

--

-- 
Dennis Clarke              OpenSolaris Governance Board Member 2010
dclarke <at> opensolaris.ca  <- Email related to the open source Solaris
dclarke <at> blastwave.org   <- Email related to open source for Solaris

Cluster, zones, noreboot.

Hi List.

A bit off-topic, but PCA's involved, so I'm going to push my luck.

We've got a number of Sun Cluster installs using (lots of) failover 
zones and with no LiveUpgrade alt. boot space set up, which we need to 
patch. If we were to patch the clusters node-by-node (including the 
kernel patches that don't like zones being booted when they're applied), 
the zones would fail over between the nodes and never get patched 
themselves, and since kernel (and some other?) patches can't be applied 
from inside zones we would end up in a situation where the zones' patch 
databases are out of sync with the Global zone. I know from very bitter 
experience that this is a Bad Thing, so to avoid that we're currently 
bringing the clusters down to patch them. This obviously isn't optimal - 
people expecting 100% uptime from the clusters are naturally a bit 
annoyed at having their applications down for several hours while we 
unleash the mighty PCA.

So, to minimise downtime I'd like to apply the noreboot patches, say, 
the night before, and have a more minimal patch run with the clusters 
down. This brings me to the question:

Has anyone ever had any problems with noreboot patches applied to live 
systems? Any weirdness at all? I've patched plenty of test machines in 
multi-user mode, but never busy production boxes - these are fairly 
large Oracle and SAP environments for the most part.

Anyone with experience patching Sun Cluster care to share any top tips?

Cheers!

Dave

Re: Cluster, zones, noreboot.

Hi there,

I have done already quit a few upgrades of sun clusters.
Can you give me some more details on what version off cluster + version 
off os.

Regards
Filip

On 07/13/10 11:52, David Stark wrote:
> Hi List.
>
> A bit off-topic, but PCA's involved, so I'm going to push my luck.
>
> We've got a number of Sun Cluster installs using (lots of) failover 
> zones and with no LiveUpgrade alt. boot space set up, which we need to 
> patch. If we were to patch the clusters node-by-node (including the 
> kernel patches that don't like zones being booted when they're 
> applied), the zones would fail over between the nodes and never get 
> patched themselves, and since kernel (and some other?) patches can't 
> be applied from inside zones we would end up in a situation where the 
> zones' patch databases are out of sync with the Global zone. I know 
> from very bitter experience that this is a Bad Thing, so to avoid that 
> we're currently bringing the clusters down to patch them. This 
> obviously isn't optimal - people expecting 100% uptime from the 
> clusters are naturally a bit annoyed at having their applications down 
> for several hours while we unleash the mighty PCA.
>
> So, to minimise downtime I'd like to apply the noreboot patches, say, 
> the night before, and have a more minimal patch run with the clusters 
> down. This brings me to the question:
>
> Has anyone ever had any problems with noreboot patches applied to live 
> systems? Any weirdness at all? I've patched plenty of test machines in 
> multi-user mode, but never busy production boxes - these are fairly 
> large Oracle and SAP environments for the most part.
>
> Anyone with experience patching Sun Cluster care to share any top tips?
>
> Cheers!
>
> Dave
>
>
>

Re: Cluster, zones, noreboot.

On 13/07/2010 12:31, Filip Francis wrote:
> Hi there,

Hi!

> I have done already quit a few upgrades of sun clusters.
> Can you give me some more details on what version off cluster + version
> off os.

Sure. It's Sun Cluster 3.2 on Solaris 10 5/08. Mainly 2 node clusters, 
but there's a 3 node and a 6 node as well. Mainly T5220 machines hooked 
up to EMC Symmetrix storage. The hosts' / slices are all UFS, all the 
zones and data filesystems are ZFS.

> Regards
> Filip

Cheers!
Dave

> On 07/13/10 11:52, David Stark wrote:
>> Hi List.
>>
>> A bit off-topic, but PCA's involved, so I'm going to push my luck.
>>
>> We've got a number of Sun Cluster installs using (lots of) failover
>> zones and with no LiveUpgrade alt. boot space set up, which we need to
>> patch. If we were to patch the clusters node-by-node (including the
>> kernel patches that don't like zones being booted when they're
>> applied), the zones would fail over between the nodes and never get
>> patched themselves, and since kernel (and some other?) patches can't
>> be applied from inside zones we would end up in a situation where the
>> zones' patch databases are out of sync with the Global zone. I know
>> from very bitter experience that this is a Bad Thing, so to avoid that
>> we're currently bringing the clusters down to patch them. This
>> obviously isn't optimal - people expecting 100% uptime from the
>> clusters are naturally a bit annoyed at having their applications down
>> for several hours while we unleash the mighty PCA.
>>
>> So, to minimise downtime I'd like to apply the noreboot patches, say,
>> the night before, and have a more minimal patch run with the clusters
>> down. This brings me to the question:
>>
>> Has anyone ever had any problems with noreboot patches applied to live
>> systems? Any weirdness at all? I've patched plenty of test machines in
>> multi-user mode, but never busy production boxes - these are fairly
>> large Oracle and SAP environments for the most part.
>>
>> Anyone with experience patching Sun Cluster care to share any top tips?
>>
>> Cheers!
>>
>> Dave
>>
>>
>>
>

Re: Cluster, zones, noreboot.

When a zone migrates back to a patched system, doesn't it normally 
update itself as it starts up the first time?

Have a look at the zoneadm man page, in particular the attach and detach 
sub-commands. I don't know for sure, but Sun Cluster may be smart enough 
to do the right thing and use zoneadm attach -u to bring the zone up to 
date when it attaches to the patched system.

Perhaps a quick chat with your local Sun SE to help plan things might be 
time well spent?

regards,
-glenn

On 07/13/10 21:41, David Stark wrote:
> On 13/07/2010 12:31, Filip Francis wrote:
>> Hi there,
>
> Hi!
>
>> I have done already quit a few upgrades of sun clusters.
>> Can you give me some more details on what version off cluster + version
>> off os.
>
> Sure. It's Sun Cluster 3.2 on Solaris 10 5/08. Mainly 2 node clusters,
> but there's a 3 node and a 6 node as well. Mainly T5220 machines hooked
> up to EMC Symmetrix storage. The hosts' / slices are all UFS, all the
> zones and data filesystems are ZFS.
>
>> Regards
>> Filip
>
> Cheers!
> Dave
>
>> On 07/13/10 11:52, David Stark wrote:
>>> Hi List.
>>>
>>> A bit off-topic, but PCA's involved, so I'm going to push my luck.
>>>
>>> We've got a number of Sun Cluster installs using (lots of) failover
>>> zones and with no LiveUpgrade alt. boot space set up, which we need to
>>> patch. If we were to patch the clusters node-by-node (including the
>>> kernel patches that don't like zones being booted when they're
>>> applied), the zones would fail over between the nodes and never get
>>> patched themselves, and since kernel (and some other?) patches can't
>>> be applied from inside zones we would end up in a situation where the
>>> zones' patch databases are out of sync with the Global zone. I know
>>> from very bitter experience that this is a Bad Thing, so to avoid that
>>> we're currently bringing the clusters down to patch them. This
>>> obviously isn't optimal - people expecting 100% uptime from the
>>> clusters are naturally a bit annoyed at having their applications down
>>> for several hours while we unleash the mighty PCA.
>>>
>>> So, to minimise downtime I'd like to apply the noreboot patches, say,
>>> the night before, and have a more minimal patch run with the clusters
>>> down. This brings me to the question:
>>>
>>> Has anyone ever had any problems with noreboot patches applied to live
>>> systems? Any weirdness at all? I've patched plenty of test machines in
>>> multi-user mode, but never busy production boxes - these are fairly
>>> large Oracle and SAP environments for the most part.
>>>
>>> Anyone with experience patching Sun Cluster care to share any top tips?
>>>
>>> Cheers!
>>>
>>> Dave
>>>

Re: Cluster, zones, noreboot.

No unless you have a certain version off Solaris i think this is only 
from version 10u7 or 10u8 that you have this option.
This is his problem.
The cluster will not do this for you it think this is scheduled in the 
next release of sun cluster later this year
Filip

On 07/13/10 13:54, Glenn Satchell wrote:
> When a zone migrates back to a patched system, doesn't it normally 
> update itself as it starts up the first time?
>
> Have a look at the zoneadm man page, in particular the attach and 
> detach sub-commands. I don't know for sure, but Sun Cluster may be 
> smart enough to do the right thing and use zoneadm attach -u to bring 
> the zone up to date when it attaches to the patched system.
>
> Perhaps a quick chat with your local Sun SE to help plan things might 
> be time well spent?
>
> regards,
> -glenn
>
> On 07/13/10 21:41, David Stark wrote:
>> On 13/07/2010 12:31, Filip Francis wrote:
>>> Hi there,
>>
>> Hi!
>>
>>> I have done already quit a few upgrades of sun clusters.
>>> Can you give me some more details on what version off cluster + version
>>> off os.
>>
>> Sure. It's Sun Cluster 3.2 on Solaris 10 5/08. Mainly 2 node clusters,
>> but there's a 3 node and a 6 node as well. Mainly T5220 machines hooked
>> up to EMC Symmetrix storage. The hosts' / slices are all UFS, all the
>> zones and data filesystems are ZFS.
>>
>>> Regards
>>> Filip
>>
>> Cheers!
>> Dave
>>
>>> On 07/13/10 11:52, David Stark wrote:
>>>> Hi List.
>>>>
>>>> A bit off-topic, but PCA's involved, so I'm going to push my luck.
>>>>
>>>> We've got a number of Sun Cluster installs using (lots of) failover
>>>> zones and with no LiveUpgrade alt. boot space set up, which we need to
>>>> patch. If we were to patch the clusters node-by-node (including the
>>>> kernel patches that don't like zones being booted when they're
>>>> applied), the zones would fail over between the nodes and never get
>>>> patched themselves, and since kernel (and some other?) patches can't
>>>> be applied from inside zones we would end up in a situation where the
>>>> zones' patch databases are out of sync with the Global zone. I know
>>>> from very bitter experience that this is a Bad Thing, so to avoid that
>>>> we're currently bringing the clusters down to patch them. This
>>>> obviously isn't optimal - people expecting 100% uptime from the
>>>> clusters are naturally a bit annoyed at having their applications down
>>>> for several hours while we unleash the mighty PCA.
>>>>
>>>> So, to minimise downtime I'd like to apply the noreboot patches, say,
>>>> the night before, and have a more minimal patch run with the clusters
>>>> down. This brings me to the question:
>>>>
>>>> Has anyone ever had any problems with noreboot patches applied to live
>>>> systems? Any weirdness at all? I've patched plenty of test machines in
>>>> multi-user mode, but never busy production boxes - these are fairly
>>>> large Oracle and SAP environments for the most part.
>>>>
>>>> Anyone with experience patching Sun Cluster care to share any top 
>>>> tips?
>>>>
>>>> Cheers!
>>>>
>>>> Dave
>>>>
>
>
>