Beruflich Dokumente
Kultur Dokumente
0
Technical Presentation
P/N 302-001-135
01
June 27, 2014
AppSync 2.0
Technical Presentation
F1950: Oracle Database for AIX & Linux
Aditya Sinha / Tony Nasta
Date
Agenda
Brief introduction to Oracle in AppSync
Supported platforms & versions
Supported
Supported
Supported
Supported
Oracle Software
Host Operating Systems
Host Software
Storage Platforms
Configuration information
Supported
Supported
Supported
Supported
filesystem-based configurations
ASM-based configurations
RAC configurations
VCS/HACMP configurations
Agenda
UNIX Agent/Host-Plugin Deployment Overview
UNIX Agent/Host-Plugin Settings
Copy management
Agenda
Restoring Oracle copies
Restore of Oracle copies in standalone environments
Restore of Oracle copies in RAC/cluster environments
Restore considerations & warnings
Troubleshooting
Questions & Answers
Introduction
This release of AppSync is the first to contain support for protection & copy
management of Oracle databases. As part of this effort, broad support for the
Linux and AIX host platforms were added
The focus of this release was on delivering platform & feature parity with
Replication Manager while enhancing feature support wherever possible.
Large focus on scalability and reducing overhead for discovery and file mapping
operations from RM.
In addition, we have strived to include numerous enhancements from RM and
reduce customer pain points on certain issues
RM
Communication
Application Security
None
Non-root capable
Yes
No
No
File transfer
None
OCI, TNS
Versions Supported
Oracle Database
11gR2 (11.2.0.X)
12cR1 (12.1.0.1)
Versions Supported
5.5-5.10, 6.0-6.5
Oracle Linux
5.5-5.10, 6.0-6.5
11 (SP1-SP3)
CentOS
5.5-5.10, 6.0-6.5
IBM AIX
** RPQ Only
EMC PowerPath
Linux, AIX
5.7
Veritas DMP
Linux
6.0, 6.1
Native MPIO
Linux, AIX
LVM Package
Veritas VxVM
Linux
Native LVM
Linux, AIX
Cluster Suite
IBM PowerHA
AIX
6.1, 7.1
Veritas VCS
Linux
5.5-6.1
6.0, 6.1
10
Features
CDP/CRR Bookmarks
11
Archive logs must reside on different storage devices from the rest of the database
Archive logs should be separate filesystem from other database files
Archive log filesystems should be on separate volume groups from other database files
Fast Recovery Area, if present (and marked for protection) must follow the same rules as the archive log
destinations. It does not need to share the same filesystem or underlying storage as archive logs, but it
must not use the same storage as the control files, redo logs and data files
Temp tablespaces are not protected and can be placed anywhere
Oracle
Database
lun
1
lun
2
lun
3
/redofs
data_vg
/datafs
Control files
Redo logs
Archive logs
lun
4
lun
5
/archfs
arch_vg
Data files
12
LINUX: Block devices via O_DIRECT, ASMLib disks, UDEV bindings, MPIO aliases (RHEL6 & SLES11 only)
AIX: raw devices, mknod devices
Oracle
Database
Control files
lun
1
lun
2
+DATA
Redo logs
lun
3
lun
4
Archive logs
+ARCH
Data files
13
It is required that the Grid infrastructure files, such as the Oracle Cluster Registry (OCR) and voting files
be kept on a diskgroup separate from the database if being stored on ASM. AppSync does not protect or
modify this diskgroup.
It is strongly recommended that for multiple RAC databases on the same Grid cluster that different
diskgroups be used for each database for restore granularity and storage efficiency
lun
1
lun
5
lun
2
+DATA1
Host B
lun
4
+ARCH1
+DATA2
RAC
Database 2
RAC
Database 1
lun
3
lun
6
Host A
lun
7
lun
8
+ARCH2
14
Just like with standalone databases, for each database it is required that archive logs, and the Fast
Recovery Area be located on separate ASM diskgroups (FRA only required if being protected)
In the image below, we illustrate that the archive log diskgroup must reside on different underlying
storage than the data files, control files & redo logs.
DB
instance 1
Data, control
& redo logs
lun
1
+DATA
+ASM1
RAC
Database
DB
instance 2
Host A
lun
2
+ASM2
Archive logs
lun
3
lun
4
Host B
+ARCH
15
16
AppSync Deployment
Progress will be
displayed here
New in 2.0
the add host
button in the
servers panel
is now a
drop-down
Provide single-use credentials
for the UNIX server. The initial
connection will set up keybased authentication for future
connections
To add/deploy
UNIX servers,
select Unix
Servers from this
drop-down
17
AppSync Deployment
Like Windows, you may deploy several UNIX hosts simultaneously
However, while you can deploy Windows and UNIX hosts simultaneously, you may not
deploy UNIX and Windows hosts together using the same panel
18
AppSync Deployment
Following deployment, AppSync will display all deployed host in the Servers pane
The agent plug-in version as well as any
platform/cluster information about the host is
displayed in the columns to the right of the host
19
The AIX or Linux host being deployed must have a SSHd daemon and any firewall rule must permit
a connection from AppSync server host to the AppSync agent host on port 22.
In addition to SSH, the server also utilizes SFTP connections over SSH authenticated sessions, so
the SFTP server must also be configured and running
The SSHd must support both password-based and key-based authentication mechanisms.
/etc/ssh/sshd_config settings:
PasswordAuthentication yes
PubkeyAuthentication yes
Note: AppSync only uses key-based authentication after the initial deployment, so if necessary for
security, password-based authentication can be disabled following deployment, however, it may
need to be re-enabled for hotfix installation & version upgrades.
If using root for the AppSync user, the SSHd must permit remote root login.
/etc/ssh/sshd_config setting:
PermitRootLogin yes
20
The installation path selected during deployment must match the settings in the sudoers
file, otherwise deployment will fail:
Note: the agent deployment will append appsync to the install-path if it is omitted, so if you select
/opt/emc/appsync, your sudoers file should contain /opt/emc/appsync/acp, while if you select /opt/emc, your
install path would be changed to /opt/emc/appsync and your sudoers file should still contain
/opt/emc/appsync/acp
At this time, using a sudo-based configuration will still result in the agent logs being
owned by the root user
21
Log directory: Points to the location containing AppSync host plugin log files
Maximum directory size (in Megabytes): The size the log directory may grow to before old log files are expired
Number of days to retain log files: The number of days which log files will be retained before they are expired
Note: The two settings above are not mutually exclusive, whichever limit is encountered first will cause logs to be
rotated. If an age-based log rotation policy is desired, it is recommended to set the value of the directory size very
high, while if a disk-quota based log rotation policy is desired, it is recommended to set the number of days to retain
the logs very high. If both are desired, then they can both be used.
Logging level: Normal / Debug (Normal is typically suitable, even for most diagnostic sessions
22
23
The next slide will cover the process of subscribing an Oracle database to a preexisting service plan and using it to protect the Oracle database
Once created, copies made through service plans can be expired, mounted &
unmounted, recovered as part of the mount or restored back to production.
This provides a good foundation for any number of business operations that
might require the use of these copies
24
25
26
If host B is up,
it will be used,
if host B goes
down,
AppSync will
look for
another node
to use
lun
2
+DATA
Host B
RAC
Database
lun
3
lun
4
+ARCH
Host A
AppSync
Protection
transferred to
host A since
host B was
down during
discovery
27
lun
1
lun
2
+DATA
Failover
Database
lun
3
lun
4
+ARCH
Since this is
active/passive appsync
has no knowledge of host
B since the DB was down
at the time the host is
discovered
Host B
Host A
AppSync
lun
1
lun
2
+DATA
Failover
Database
lun
3
lun
4
+ARCH
Host B
Host B
Host A
AppSync
28
Copy 2
Copy 1
Control files
Archive logs
Redo logs
Fast Recovery
Area
Data files
Optional
29
Oracle
Database
Not protected
Copy 1
Control files
Archive logs
Redo logs
Fast Recovery
Area
Data files
Optional
30
VNX Considerations
For crash-consistent copies without hot backup, AppSync omits the archive logs
and only creates a single copy unless the optionally included FRA is also
marked for protection
In a crash-consistent copy, there is no requirement that the archive logs reside on
separate storage, since they are not protected, but the FRA still must adhere to this
requirement if it is marked for protection.
Oracle
Database
Not protected
Copy 1
Control files
Archive logs
Redo logs
Fast Recovery
Area
Data files
Optional
31
32
33
34
35
36
Using the same settings as on the previous slide, here is an example of a manual script based
recovery.
After AppSync is done with the mount and recover of the copy the recovery scripts can be
found on the mount host under the /tmp/<ORACLE_SID>/RecoveryScripts directory. There will be
a total of four script files found there, each with a step number and operation in the filename.
The user has to now run the script files in order of the step numbers to recover the database.
There are two different types of scripts, an SQL script (*.sql) and an RMAN script (*.rman).
Before running any of the scripts the mount host has to be configured with the correct
ORACLE_HOME and ORACLE_SID settings. (NOTE: The ORACLE_SID in this case is the new
SID after the rename operation T%DB%)
To run a SQL script the user has to login into sqlplus on the command line, this can be done
as follows from inside the ORACLE_HOME/bin directory with the following command,
./sqlplus / as sysdba
Similarly to login into rman the user would enter rman target=/ and enter the following to
run the script.
@ /tmp/<ORACLE_SID>/RecoveryScripts/Step-<Number>_Operation.rman
37
Step2:
38
Step3:
Step4:
39
40
perform RAC mount from N->N, N->N+ or N->N- cluster configurations. For
to 2-node (N->N)
to 4-node (N->N+)
to 2-node (N->N-)
The selected SID name serves as a base name for the SID and does not include the instance
number, additionally, the %SID% variable in the mount dialog represents the base SID of the
production RAC database.
Example: User protects database racdb which has instances RACDB1 & RACDB2, the base SID here is
RACDB.
If a SID name setting of %SID%X is used and they are mounting to a 3-node Grid cluster, the resulting
instances will be:
RACDBX1
RACDBX2
RACDBX3
41
If affected databases will also be restored to the point in time the copy of the original was at.
Any application consistency that was applied to the original copy will not be available for the impacted
databases (they are crash consistent after restore).
AppSync will not shut them down or dismount any filesystems unique to these databases, so this must
be done manually prior to restore
42
43
44
Troubleshooting Tips
Symptom: Host was successfully added to AppSync, but no Oracle
databases are available for copy management.
Probable cause: Databases or instances were down, or entries not present in
/etc/oratab file
Solution: Restart the databases or add the relevant entries to the /etc/oratab file,
then perform a host discovery through the product.
45
Troubleshooting Tips
Symptom: Mount & recovery fails with error Could not detect valid
Grid home
Probable cause: Oracle Grid infrastructure is not installed
Solution: Install Oracle grid infrastructure and make sure that a default
ASM instance is running
Symptom: Mount & recovery fails with error Failed to mount ASM
diskgroup
Probable cause: Oracle SP file
Solution: Install Oracle grid infrastructure and make sure that a default
ASM instance is running
Symptom: Mount & recovery fails with error Database needs more
recovery to be consistent
Probable cause: Using VNX advanced snaps without consistency groups
Solution: At minimum, the Oracle archive log disks must be contained
within a VNX consistency group
46
47
THANK YOU
48
AppSync 2.0
Technical Presentation
VMAX Support with AppSync2.0
49
Agenda
VMAX Array discovery and configuration
Storage mapping and protection
Mount of VMAX copies
Restore
Lun restore
VM restore
50
51
52
53
54
55
56
57
58
59
60
61
62
Using dedicated Storage Group (one or more) for copy devices only
Create one or more Storage Group with no host connectivity(not attached to any
LUN masking view)
Provision new target devices for application copies matching source device size and
type and add this to Storage Group created
For VP-SNAP, make sure target device is also thin provisioned. If source already has VP-SNAP from a thin
pool, make sure target copy device is also provisioned in same pool
For META devices make sure target is also meta matching META type e.g. striped or concatenated
In case application already has existing clone/VP-SNAP session created, put the
target devices of those session in the one of the storage group created for AppSync
purpose. AppSync can read existing session information and reuses them.
All devices in the configured storage group(s) are used as copy devices, so
never add any production/Source device into these Storage Groups as it
will result in data loss erasing all the production data.
Dont share same storageGroup(s) across multiple AppSync server
63
Using dedicated Storage Group (one or more) for copy devices only
As shown in picture next, AppSync discovers all the storage group on
selected VMAX system which doesnt have any host connectivity i.e. not
attached to any LUN masking view and list all of them in the groups and
Pools section of Add VMAX Storage wizard.
To configure a Storage Group for AppSync target device selection, user
need to enable it by clicking on the check box next to the storage group.
AppSync allow selecting multiple storage groups.
Once end user selects Storage Group(s)whose devices he intends to use
as replication/copy storage devices, upon pressing finish he gets to see
the warning screen below which warn end user to review his selection
once more time as all the devices in the selected storage groups will be
used as vp-snap or TF clone target copy devices and original data on
those devices gets lost
64
65
66
Using dedicated Storage Group (one or more) for copy devices only
At any point of time if end user needs to know what storage groups were
selected for replication purpose and how many devices overall were
enabled for replication(vp-snap and clone) target, he can select his vmax
system in the settings tab and the pane below displays all those details(as
shown in picture below
67
68
Using dedicated Storage Group (one or more) for copy devices only
User can select also the Manage copy storage button to enable/disable
storage groups for any discovered vmax array(as shown in picture next)
At any time user wants to disable any enabled storage group so that
AppSync no longer uses devices from those storage groups for
replication purpose, he can use the same wizard and just deselect the
check box.
If any device is used as a valid appsync copies, AppSync performs the necessary checks
and throw relevant error message and doesnt let user disable that storage group(s)
AppSync doesnt terminate differential clone session when storge group(s) are
disabled.
69
70
71
72
73
74
75
76
77
78
79
80
81
82
Protection
83
84
Before creating VMAX copies appsync needs to pair each of the source
devices on which application data resides to a corresponding target
device.
Appsync follows a set of rules for pairing source and target devices for
VP SNAP and TF clone copies.
Next slides have few of the rules captured while pairing source and
target devices. The rules for VP Snap and TF clones are slightly
different.
85
86
4. If AppSync doesnt find any target till 3 above and no valid pool is
configured, it considers any target device which had a pre-existing
session but is not being used for any copy and it terminates its earlier
sesison and reuses
87
Protection VP SNAP
88
Protection
89
mapping the source storage devices to VMAX devices and identifying the VMAX
system,
2.
pairing the source devices with suitable target devices i.e. SPA. If required
AppSync provisions the target LUN in the StoragePool configured for AppSync use.
3.
4.
5.
6.
7.
90
Protection
91
Protection TF Clone
92
Protection
93
mapping the source storage devices to VMAX devices and identifying the VMAX
system,
2.
pairing the source devices with suitable target devices i.e. SPA. If required
AppSync provisions the target LUN in the StoragePool configured for AppSync use.
3.
creating an unactivated and differential TF clone session between the source and
target
4.
5.
6.
7.
8.
94
Protection
95
96
97
98
99
100
101
102
103
104
105
THANK YOU
106
AppSync 2.0
Technical Presentation
F:1923 RecoverPoint on VMAX
107
Agenda
Protection
Mount
Restore
License
108
Protection
All the use cases supported on RP-VNX is
supported for RP-VMAX from AppSync 2.0
onwards.
109
Mount
Only Logged access is supported due to
restriction from symmetrix splitter
110
RP Dynamic Mount
Dynamic mount of RP Targets is supported if
the underlying storage is VMAX.
AppSync uses VMAX auto provisioning
capabilities to add LUNs dynamically to a
mount host.
Register the SMI-S Provider managing the
VMAX array.
Please refer to the VMAX Dynamic Mount
instructions for details on the setup.
111
Restore
All use cases similar to VNX is supported
112
License
No License needed.
113
Troubleshooting Tips
If mount takes more than 30 minutes, then
please increase the value of server setting
variable max.timeout.enable.image. The
value is accepted in seconds.
114
THANK YOU
115
AppSync 2.0
Technical Presentation
F1940 AppSync and RM or NMM co-existence
Dee Holly
June 6, 2014
116
Agenda
Introduction
AppSync VSS Hardware Provider
AppSync Exchange Interface service
Upgrade
Coexistence
Troubleshooting
117
Introduction
Before AppSync 2.0, AppSync, RM, and NMM
could not be installed on the same server
Starting with 2.0, AppSync can be installed on a server
with RM or NMM or NetWorker Client
RM and NMM still cannot coexist.
118
Hardware Providers
AppSync 1.5 and 1.6
Provider name: 'AW VSS Provider'
Provider type: Hardware
Provider Id: {e929a027-cf8c-47bf-90a3-cd4241c7cace}
Version: 1.0
Replication Manager
Provider name: 'ERM VSS Provider'
Provider type: Hardware
Provider Id: {e929a027-cf8c-47bf-90a3-cd4241c7cace}
Version: 1.0
AppSync 2.0
Provider name: 'AppSync VSS Provider'
Provider type: Hardware
Provider Id: {f2a06f22-aa08-481c-a9ca-8c01761d4fa0}
Version: 1.0
119
120
AppSync 2.0
Exchange Interface service
121
Upgrade
AppSync Exchange Interface service has to
be reconfigured during upgrade
Manual upgrade will ask for user credentials
to reconfigure the AppSync Exchange
Interface service
Push install upgrade will also ask for
credentials.
One set of credentials for all of the servers
currently be upgraded
122
5.
Restarts the AppSync Host Plug-in to make sure the hardware provider
registers properly
123
Upgrade Example
124
125
126
AppSync
AppSync
AppSync
AppSync
127
128
129
Troubleshooting Tips
If, after upgrade, customers are getting strange
errors about the provider, use vssadmin list
providers to verify that the provider is registered
with the new name and Id
If customers are not able to discover databases,
verify that the EMC AppSync Exchange Interface
DCOM component is registered with the new AppId
and the credentials are correct.
Also make sure that the EMC AppSync Exchange Interface
service is running
130
131
132
THANK YOU
133
AppSync 2.0
Technical Presentation
F1940 AppSync and RM or NMM co-existence
Dee Holly
June 6, 2014
134
Agenda
Introduction
AppSync VSS Hardware Provider
AppSync Exchange Interface service
Upgrade
Coexistence
Troubleshooting
135
Introduction
Before AppSync 2.0, AppSync, RM, and NMM
could not be installed on the same server
Starting with 2.0, AppSync can be installed on a server
with RM or NMM or NetWorker Client
RM and NMM still cannot coexist.
136
Hardware Providers
AppSync 1.5 and 1.6
Provider name: 'AW VSS Provider'
Provider type: Hardware
Provider Id: {e929a027-cf8c-47bf-90a3-cd4241c7cace}
Version: 1.0
Replication Manager
Provider name: 'ERM VSS Provider'
Provider type: Hardware
Provider Id: {e929a027-cf8c-47bf-90a3-cd4241c7cace}
Version: 1.0
AppSync 2.0
Provider name: 'AppSync VSS Provider'
Provider type: Hardware
Provider Id: {f2a06f22-aa08-481c-a9ca-8c01761d4fa0}
Version: 1.0
137
138
AppSync 2.0
Exchange Interface service
139
Upgrade
AppSync Exchange Interface service has to
be reconfigured during upgrade
Manual upgrade will ask for user credentials
to reconfigure the AppSync Exchange
Interface service
Push install upgrade will also ask for
credentials.
One set of credentials for all of the servers
currently be upgraded
140
5.
Restarts the AppSync Host Plug-in to make sure the hardware provider
registers properly
141
Upgrade Example
142
143
144
AppSync
AppSync
AppSync
AppSync
145
146
147
Troubleshooting Tips
If, after upgrade, customers are getting strange
errors about the provider, use vssadmin list
providers to verify that the provider is registered
with the new name and Id
If customers are not able to discover databases,
verify that the EMC AppSync Exchange Interface
DCOM component is registered with the new AppId
and the credentials are correct.
Also make sure that the EMC AppSync Exchange Interface
service is running
148
149
150
THANK YOU
151