My actual customer has bought two Oracle Database Appliances, ODA X7-2 HA, and they are migrating all Oracle databases with different versions from the old, VMWare based, Windows environment to the ODA (Virtualized Platform).
After the successful deployment of the ODAs in the customers vlan (maybe worth another post) the question was, how to put the things from the old environments to the ODAs.
Secure copy (scp/Puttys pscp) is ok, but either you need to install putty everywhere or you need to map all server drives at your client and (p)scp all to the ODAs,... not really a fun task.
Also you have an additional step if you create e.g. the RMAN backup locally at the Windows server and then (p)scp it to the ODA. You know it's an additional step which means (down) time and money, so we wanted to avoid this for the time of the migration.
As nfs was not a solution (due to some internal configuration issues) we thought about creating a direct connection between the ODAs and the Windows servers.
CloudFS is a nice feature of ACFS (not only) on the ODAs, but it can't be used without some additional configuration to map a drive at the Windows Server or to use UNC from RMAN or as directory for Datapump Exports to the ODA.
The customer wants to allow the Windows Server for the time of the migration of all databases to write from any machine directly (without to set any user/password) to the CloudFS on the ODA X7-2 HA, so we had to configure Samba (smb) at the ODA.
If you may need it, here are the steps you can walk through if you want to use CloudFS within UNC paths or if you need to map the CloudFS directory from the ODA to your Windows Server without user/password.
- Ensure, that CloudFS is configured and sized right to have enough space for your files. Typically, CloudFS is created when the ODA_BASE is deployed, but you can skip this step. If you have skipped it, you can create CloudFS using the asmca (ASM Configuration Assistent) or you can do it manually. I didn't need it, but I think Matthew described in his cloudfs post very well, how to do it if you don't want to use asmca. Even resize can be done very easy by following this oracle support note.
To check the existence and the size of your CloudFs, run
df -h /cloudfs
CloudFS is mapped on both ODA nodes to /cloudfs. Owner:group should be oracle:oinstall.
- Configure Samba at the ODA_BASE (as root), part GLOBAL
You need to edit the smb.conf file which is located at /etc/samba:
vi /etc/samba/smb.conf
Skip to - roundabout - line 100 (Standalone Server Options). There you can see this configuration:
security = user
passdb backend = tdbsam
Change this (even if it's marked deprecated to use security = share) to:
security = share
passdb backend = tdbsam
guest account = oracle
- Configure Samba on both nodes with the name and the rights of your share.
Now it's time to bring your share configuration into the smb.conf file. At approx. line 255 the "Share Defnitions" part starts. There you do need to put in the configuration for your share. The part in [ ] is the name you later see if you use your Windows explorer - so it's the public name of the share: We named it ODAPROD_CLOUDFS, but typically only CLOUDFS is enough.
[ODAPROD_CLOUDFS]
comment=cloudfs files
path=/cloudfs
browsable=yes
public = yes
writable = yes
printable = no
After you have inserted this write the smb.conf and quit from vi.
- Copy the smb.conf to second node
To be able to use the share "high available" later on, copy the changed smb.conf from your local nodes /etc/samba/smb.conf to the second node using scp.
- Start / Stop the Samba Service on both nodes.
You need to start the service at both nodes manually.
To do this, connect as root to ODA_BASE on both nodes and run
service smb start
If you want to stop the Samba share, you can run
service smb stop
- Test UNC path from Windows
You can now test the connection. Open a File Explorer Window at MS Windows. Then you should be able to use the share. Don't use the node names to connect to the share, use the SCAN name of the system, so you are able to use the share even if one of the nodes is not available, e.g. while reboot.
In my case, we can now use the UNC path from Windows without to specify a user/password to write into /cloudfs at the ODA using in Windows explorer:
\\ODA-SCAN\ODAPROD_CLOUDFS
You could also map the share as drive in Windows using the net use command.
Now we can make backups from the Windows server direct to the ODA, using e.g.
backup database format '\\ODA-SCAN\ODAPROD_CLOUDFS\%U';
In addition, we don't need to install putty on all windows servers to pscp e.g. the VM templates for the application VMs we want to use at the virtualized platform.
- As this configuration don't need a username and password, you should start and stop the smb service explicitly - don't let it run all the time, start it when needed and stop it if you have put everything onto the ODA.
It's a question of security and you sure don't want that someone uses the storage of the ODA to put some photos or videos on and share it. - If you need the cloudfs share as a long term solution, use the standard configuration with security, add your share to the smb.conf and map the drive on the MS Windows systems you need it.
- I don't have registered the smb service to the cluster infrastructure (as it is - in our case - only started when needed). If you want to keep the smb share(s) (so SMB is automatically started after ACFS/databases/...) you can configure that - the solution would be: crsctl add resource.
An example can be found (for Samba) at the documentation of Oracle (this link is for version 12.1)
