From: Alexei_Roudnev (Alexei_Roudnev_at_exigengroup.com)
Date: Thu Mar 02 2006 - 23:09:42 CET
Message-ID: <1b1501c63e46$01eefc30$6f31a8c0@sjc.exigengroup.com> From: "Alexei_Roudnev" <Alexei_Roudnev@exigengroup.com> Date: Thu, 2 Mar 2006 14:09:42 -0800 Subject: Re: [suse-sles-e] OCFS2 support
Ok.
I mean, that to be _production grade_, something must be well tested under
REAL load.
Real load means one of
- serious stress testing and failure testing (which is pretty tricky for the
cluster systems - for example, you must test ALL possible
failure scenarios.
- real load in many installation and enough time to reveal problems because
of _they really happen_.
With OCFSv2, we have for now:
- good testing by Oracle for Oracle related data ONLY. For example, it means
that they store HOME but means that they did not tested,
what happem if node-1 is ACTIVELY created and deleted files and NODE-2 is
created and deleted THE SAME files with different user ID, and what happen
if node-1 rename file and node-2 delete it AT THE SAME TIME, and (at the
same time) nodes lost interconnection, etc etc....
- very smal installation base except for Oracle - related things.
It means that it is _relatively_ safe for Oracle in production, safe for
_Oracle style usage_ (example - keep shared /usr/share directory - usage
profile is exactly the same as for ORaCLE_HOME), and is not safe for such
things as file server with numerous concurrent access sessions (NFS sever
for example). People started to use it for different tasks, so may be in 1/2
year - 1 year we wil be able to treat it as _production grade_ for other
tasks as well.
It have nothing with SUPPORT - which is just MARKETING TERM, nothing more
(but based on, correct, real testing). For example, no matter if Oracle say
_we support database on OCFSv2_ - I better will not use it for production
database (but wil use it for archive logs and backups on such database) -
because I have not reason to believe that it is REALLY TESTED by them in all
failure modes - seen how other components work, I think that it is not
really well tested even for certified configurations. I am trying to
predict, which configurations and usage patterns are _REALLY_ well tested,
and which are _SAFE TO USE_ even with current level of testings, and avoid
other (no matter if are they certified or are not). Of course, in production
system you (THEN) make 'AND' between your choices and CERTIFIED matrix and
use only those which are safe for YOU and are CERTIFIED; but in many other
you choice will be the only one which make sense (and use certification
matrix for information only). --X-- cables are a good example (use --x-- in
development? - of course, YES even if it is our Project system or our assetr
management system - why pay extra money for nothin?. Use --x-- in
production - not until Oracle says YES.).
----- Original Message -----
From: "Dr J Pelan" <J.Pelan@gatsby.ucl.ac.uk>
To: "Alexei Roudnev" <Alexei_Roudnev@exigengroup.com>
Cc: <suse-sles-e@suse.com>
Sent: Thursday, March 02, 2006 12:07 PM
Subject: Re: [suse-sles-e] OCFS2 support
>
> On Tue, 28 Feb 2006, Alexei Roudnev wrote:
>
> > Problem is not in support.
>
> Please read the thread, then you will see it was specifically addressing
> the issue of *support* from Oracle when used with the Oracle db.
>
> > Problem is that for now, OCFSv2 have not enough installation base in all
> > _non Oracle related_ cases to be treated as _production grade stable_.
> > So, for example, I should not use it for file server (OCFSv2, SAMBA +
> > NFS over it).
>
> That all depends on how you define 'production grade stable' and how you
> act on that essentially subjective judgement. It is a circular argument to
> suggest that it isn't ready for production until it is used in production!
> Each case for deployment must be based on its own merits, including
> fitness for purpose and costing failure. For some, OCFSv2 - like many
> packages of a similar vintage and usage level - will be production ready.
>
> --
> John P.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
> For additional commands, e-mail: suse-sles-e-help@suse.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Thu Mar 02 2006 - 23:10:44 CET