Just end of thread so far, not really a reply to Tim other than to state as NOT
a Delphix employee that every single person or place I know of that has adopted
Delphix has been happy with the choice.
On the issue of a single lun, however, I do have an opinion: It really depends
on whether or not the single lun is reliably multiplexed at the device level
with software and/or hardware you trust and whether the latency and bandwidth
to the single lun is good enough for the service level desired through its
various channel connections from persistent media to the consumer CPUs.
There is a lot of presumed knowledge in the sentence above, but since this is
oracle-l I won’t repeat what I think most folks know.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Tim Gorman
Sent: Friday, June 30, 2017 12:44 PM
To: ian@xxxxxxxxxxxxxxxxx
Cc: ORACLE-L
Subject: Re: A Very Basic Oracle on VmWare System
Ian,
I'll throw this out there...
Delphix manages virtual Oracle databases and virtual ORACLE_HOME binaries,
which are presented to database servers using NFS mounts. Because they are NFS
mounted, they are fast and easy to unmount and remount to another database
server (a.k.a. VDB migration). Downtime is still required, as VDB and vFile
migration requires that the database instance be shutdown and restarted, but
the VDB migration operation takes minutes regardless of the size of the
database and binaries, and can be operated from a graphical console or
automated from an API. ORACLE_HOME binary virtualization is only a convenient
option if desired, and that locally-installed ORACLE_HOME binaries are
certainly common and supported.
Virtual databases are not intended for mission-critical production usage, only
for non-production usage (i.e. DEV, TEST, etc) or non-mission-critical or
temporary production usage. Not sure if you're considering VMs for production
usage anyway?
Virtualization ain't just for servers anymore...
Hope this helps...
-Tim
Disclaimer: I work for Delphix
On 6/30/17 09:25, MacGregor, Ian A. wrote:
I was hoping to check with my VM admin before I replied, but could not. I
do know the methodology she is using moves the entire VM, both files and
processes. The had mentioned one VM which takes 20 minutes to move due to the
size of its associated files. I thought she was doing this through vMotion,
but I may be wrong. Anyway, even if vMotion is the methodology, it sounds as
if normally it is only used to migrate processes and not files.
Thanks you for the assistance
Ian
On Jun 29, 2017, at 6:10 AM, Andrew Kerber <andrew.kerber@xxxxxxxxx> wrote:
Vmotion is only possible on shared storage. But no, a single physical lun does
not provide enough protection. Most people use a san for their storage in
VMware, your configuration is unusual in that it is on local disks.
On Wed, Jun 28, 2017 at 2:38 PM, MacGregor, Ian A. <ian@xxxxxxxxxxxxxxxxx>
wrote:
Seth both. I don’t see how a single physical LUN provides enough
protection. As far as moving of the databases is the even possible with this
setup?
IAN
On Jun 28, 2017, at 11:57 AM, Seth Miller <sethmiller.sm@xxxxxxxxx> wrote:
Ian,
Can you clarify your concern? Is the problem that you can't migrate your
databases without taking an outage, or that the LUN doesn't offer enough
protection for your database files?
Seth Miller
On Wed, Jun 28, 2017 at 1:39 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx> wrote:
Most people run their VM's over shared storage, which allows for vmotion and
storage vmotion. When I am setting up small stuff, not enterprise, but want to
make sure of the data I use ASM and ASM native data protection, ie standard
redundancy. On the OS side, we can use snapshots.
On Wed, Jun 28, 2017 at 11:05 AM, MacGregor, Ian A. <ian@xxxxxxxxxxxxxxxxx>
wrote:
We run our VMs on local disk; i.e, no SAN or NAS. Let’s say physical machine
a has 24 disks. The standard configuration to create a 22 disk RAID 10
physical LUN. Then carve the virtual file systems out of that. I don’t like
this idea because, to doesn’t provide enough protection for the control and
online redo log files.
The reason for setting up one physical LUN is to allow for VM migration.
I presently have several small databases running on several VMs. I
insisted on at least two physical LUNs. The inability to migrate VMs means
the possibility of additional outages should their hypervisors need to be
shutdown, and the outage cannot be coordinated with other patching. So the
only databases I have on VMs are ones which do not have to be up 24 X 365
I’m not sure how VmWare has become so popular with this restriction. We are
replacing our present physical machines which host the VMs. The main
difference is the new servers are all SSD. This is highly attractive, but
the VmWare administrator has indicated their will be no exceptions for Oracle
If it is standard to care the VM file systems out of one physical LUNs what is
being done to protect the control file and redo logs.
Ian MacGregor
SLAC National Accelerator Laboratory
ian@xxxxxxxxxxxxxxxxx
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
