A lot of people are using Oracles KVM solution on ODA (Oracle Database Appliance). My company e.g. runs something like application servers in a Linux VM on the ODA lite models for our own software solutions (like communication server, etc.) if a customer runs ODAs (we call it "Solution-in-a-Box"). But there are also other customers, where we just act as system integrator, who want to use KVM on the ODA.
There is a really nice blog how to enable and use KVM on ODA, the starting point is this blog post by Tammy: kvm-on-oda.
It is straight forward, but one of the things are a little bit crucial. It is how to make the network configuration for the KVM on ODA. The best solution is to BRIDGE the network. Ruggero has written a blog post as part of Tammys blog, how you can enable all the different network types.
Don't use NAT or MacVTap - just follow the configuration steps for "Bridged networking (aka "shared physical device")".
Be sure you have access to the iloms host redirection function, because if there is any misconfiguration with the bridge, you lose the network connectivity und you are not able to connect internal (like you could do with ODA HA).
If you have followed the configuration steps and if you can connect to the ODA host again with the bridge configuration, you are not able to connect to the database(s) on that host anymore. Why? Because one mandatory step is missing at Ruggeros example: The configuration of the clusterware (as grid user)! Some tried to stop and start the listener, but the listener will not be started and errors out.
What you need to do as a last configuration step is to modify your clusterware network configuration. The listener is bound to Network 1, which can easily seen by issueing
$ srvctl config listener
Name: LISTENER
Type: Database Listener
Network: 1, Owner: grid
Home: <CRS home>
End points: TCP:1521
Listener is enabled.
Listener is individually enabled on nodes:
Listener is individually disabled on nodes:
To check the configuration, run the following command:
$ srvctl config network
Network 1 exists
Subnet IPv4: 10.214.0.0/255.255.248.0/btbond1, static
Subnet IPv6:
Ping Targets:
Network is enabled
Network is individually enabled on nodes:
Network is individually disabled on nodes:
As you can see, the network is still configured to btbond1 instead of pubbr0.
The syntax (I use the same subnet in my example as Ruggero in his blog) to change this is:
$ srvctl modify network -netnum 1 -subnet 10.214.0.0/255.255.248.0/pubbr0
Now it is best to either restart the ODA to check if everything is running fine also after an reboot or at least to restart the listener.
$ srvctl stop listener
$ srvctl start listener
Then you are done folks, you can use the bridged device now for your KVM and the databases are reachable again.
Showing posts with label X7-2 M. Show all posts
Showing posts with label X7-2 M. Show all posts
How to change the timezone on ODA lite models
At a customers ODA (the one we have deployed using a json file) we have seen a problem right before going into production. The timezone was set wrong due to a typo mismatch in the json file. CET is the Central European Timezone while ECT is the Ecuador Timezone and in addition to this we have also used UCT.
Redeploying is not funny if you have everything installed you need (including KVMs) on the ODAs, data guard works and the users finished the application tests already.
So we needed to do a change of the timezone without redeploying, and, as the system is placed in Switzerland, to specify the timezone Europe/Zurich is even better than specifying CET (even logically it is the same).
But typo mismatch isn't the only reason to change the timezone like Oracle mentions:
If you try do to the first steps of the note, you will see, that "onecommand.params" at "/opt/oracle/oak/onecmd" does not exists and you also search unsuccessfully for the "GridInst.pl" command file, which should be located in the same directory.
We recently managed to change the timezone on the ODA lite model by following this approach,which is a mixture of plain Linux and Doc ID 1519975.1:
1.) Connect as root to the system
2.) Check the timezone of the system:
[root@ODA1 ~]# date
Tue Feb 20 10:05:49 UTC 2018
3.) Remove the symbolic link localtimezone from the /etc directory
[root@ODA1 ~]# cd /etc
[root@ODA1 etc]# rm localtime
rm: remove symbolic link `localtime'? yes
4.) Create a new symbolic link "localtime" to the right timezone located at /usr/share/zoneinfo/*, in my example it is Europe/Zurich:
[root@ODA1 etc]# ln -s /usr/share/zoneinfo/Europe/Zurich localtime
5.) Check if the timezone of the system is now correct:
Now the node itself is running with the correct timezone and we can follow the approach of the Oracle note.
6.) The next step is to set the environment for all databases we do have using srvctl. Therefore you must connect as user "oracle", have set the environment (running oraenv) and change the timezone for the database:
[oracle@ODA1 ~]$ . oraenv
ORACLE_SID = [oracle] ? MYDB
The Oracle base has been set to /u01/app/oracle
[oracle@ODA1 ~]$ srvctl setenv database -d MYDB_ODA1 -t TZ=Europe/Zurich
7.) Repeat srvctl setenv database for all databases you run on the ODA using the corresponding environment (oraenv).
8.) Now you have to connect as grid user to the ODA and modify a file. The folder the file is located in is "/u01/app/<yourversion>/grid/crs/install" and the file is named "s_crsconfig_<yourODAhost>_env.txt.
For our environment we did the following:
[grid@ODA1 ~]$ vi /u01/app/12.1.0.2/grid/crs/install/s_crsconfig_oda1_env.txt
In vi then change the "TZ=<value>" line, e.g. in our environment it was changing
TZ=ECT
to
TZ=Europe/Zurich.
You need to write the file with force (!wq) after you have changed the line.
9.) Next step is to restart the Grid Infrastructure, e.g. by rebooting the system.
10.) The last step needed to do is to change the environment for ASM also.
So again connect as grid user to the ODA and execute:
[grid@ODA1 ~]$ srvctl setenv asm -t TZ=Europe/Zurich
[grid@ODA1 ~]$ srvctl getenv asm
asm:
TZ=Europe/Zurich
That's it folks - you are done!
Redeploying is not funny if you have everything installed you need (including KVMs) on the ODAs, data guard works and the users finished the application tests already.
So we needed to do a change of the timezone without redeploying, and, as the system is placed in Switzerland, to specify the timezone Europe/Zurich is even better than specifying CET (even logically it is the same).
But typo mismatch isn't the only reason to change the timezone like Oracle mentions:
- Mistaken value during deployment
- New timezone values or definitions for business reasons
- Change order to enforce (or disregard) daylight savings values (DST)
- New usage of timezone dependent functionality including Grid Control, EM Agent or Dbconsole settings
- Enforce business rules or auditing based on specific time / timezones
- Reinstallation
If you try do to the first steps of the note, you will see, that "onecommand.params" at "/opt/oracle/oak/onecmd" does not exists and you also search unsuccessfully for the "GridInst.pl" command file, which should be located in the same directory.
We recently managed to change the timezone on the ODA lite model by following this approach,which is a mixture of plain Linux and Doc ID 1519975.1:
1.) Connect as root to the system
2.) Check the timezone of the system:
[root@ODA1 ~]# date
Tue Feb 20 10:05:49 UTC 2018
3.) Remove the symbolic link localtimezone from the /etc directory
[root@ODA1 ~]# cd /etc
[root@ODA1 etc]# rm localtime
rm: remove symbolic link `localtime'? yes
4.) Create a new symbolic link "localtime" to the right timezone located at /usr/share/zoneinfo/*, in my example it is Europe/Zurich:
[root@ODA1 etc]# ln -s /usr/share/zoneinfo/Europe/Zurich localtime
5.) Check if the timezone of the system is now correct:
[root@ODA1 etc]# date
Tue Feb 20 11:07:54 CET 2018
Tue Feb 20 11:07:54 CET 2018
Now the node itself is running with the correct timezone and we can follow the approach of the Oracle note.
6.) The next step is to set the environment for all databases we do have using srvctl. Therefore you must connect as user "oracle", have set the environment (running oraenv) and change the timezone for the database:
[oracle@ODA1 ~]$ . oraenv
ORACLE_SID = [oracle] ? MYDB
The Oracle base has been set to /u01/app/oracle
[oracle@ODA1 ~]$ srvctl setenv database -d MYDB_ODA1 -t TZ=Europe/Zurich
7.) Repeat srvctl setenv database for all databases you run on the ODA using the corresponding environment (oraenv).
8.) Now you have to connect as grid user to the ODA and modify a file. The folder the file is located in is "/u01/app/<yourversion>/grid/crs/install" and the file is named "s_crsconfig_<yourODAhost>_env.txt.
For our environment we did the following:
[grid@ODA1 ~]$ vi /u01/app/12.1.0.2/grid/crs/install/s_crsconfig_oda1_env.txt
In vi then change the "TZ=<value>" line, e.g. in our environment it was changing
TZ=ECT
to
TZ=Europe/Zurich.
You need to write the file with force (!wq) after you have changed the line.
9.) Next step is to restart the Grid Infrastructure, e.g. by rebooting the system.
10.) The last step needed to do is to change the environment for ASM also.
So again connect as grid user to the ODA and execute:
[grid@ODA1 ~]$ srvctl setenv asm -t TZ=Europe/Zurich
[grid@ODA1 ~]$ srvctl getenv asm
asm:
TZ=Europe/Zurich
That's it folks - you are done!
Edit March 2021:
- First:
On newer ODA versions you can also update the registry (internal database) to reflect the change.
If you run an odacli describe-system you will get the old timezone if you don't run:
# odacli update-registry -n system -f
- Second: There is a bug that SYSDATE may be wrong after migrating from ODA Release 18.x to 19.x. Please check, using vi /u01/app/12.1.0.2/grid/crs/install/s_crsconfig_oda1_env.txt, that the timezone isn't specified with any ' ' or " " in the file. If so, change it back. Also check with srvctl getenv all listeners, databases and asm if the right time zone is still enabled. If you set them manually restart all parts affected by the change.
Subscribe to:
Posts (Atom)