Weblogic Server Administration Admin Guide Prepared By Harish V1.1
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 82
| Download | |
| Open PDF In Browser | View PDF |
2014
Weblogic Server Administration
Harish
harishweblogictraining@gmail.com
12/15/2014
Content:
Why Application servers came into picture
Webserver
Application Server
Diff b/w Application Server and WebServer
Introduction to weblogic server
Weblogic Server Introduction
Diff b/w WLS Versions (9.x,10.x ,11.x and 12c)
Installation Guide
Installation Modes
o GUI Mode Installation
o Command Mode Installation(in Linux)
o Silent Mode Installation
History of Weblogic Domain
Configuration Modes
o GUI Mode Installation
o Command Mode Installation (Linux)
Domain Creation Using Pack & Unpack Commands
Pack
Unpack
Start & Stop Servers
Start & Stop Weblogic Server (win/Linux)
Start & Stop Manage Servers
History of Boot.properties
Configure boot.properties
History of NodeManager
Types of NodeManager
Configure NodeManager in Weblogic Server
CLUSTER
History of Cluster
- Cluster Relate to a weblogic Domain
- Benefits of Clustering
o Scalability
o High-Availability
Types of Cluster’s
o Vertical Cluster
Configure Vertical Cluster
o Horizontal Cluster
Configure horizontal Cluster
Unicast & Multicast
Load Balancing in a Cluster
Failover &Replication in a Cluster
o Benefits of Clustering
Scalability
High-Availability
o Failover and Replication in a Cluster
WebLogic Server Detects Failures
WebLogic Server Heartbeat
o Replication and Failover for Servlets and JSPs
Hardware load balancers
Proxy plug-ins
o HTTP Session State Replication
In-memory replication
JDBC-based persistence
Cluster Architectures
Deployments
Weblogic Deployments
Modes of Deployments
o STAGE Mode deployments
o NO-STAGE Mode deployments
o External-STAGE Mode deployments
Types of Deployments
o Console Mode deployments
o Command Mode deployments
Side by Side deployments
o WLST deployments
o ANT deployments
o Auto deployments
JDBC
Weblogic Server JDBC Resources
Configuring Weblogic JDBC Resources
Datasource
Connection-Pool
JDBC Driver
o Generic Data source
Statement Cache Algorithms
LRU (Least Recently Used)
Fixed
o
o
Statement Cache Size
Grid link Data source
Fast Connection Failover
Runtime Connection Load Balancing.
Graceful Handling for Oracle RAC Outages
XA Affinity
Multi-Data source
JMS
JMS
ConnectionFactory
Queue (Point-to-Point Messaging)
Topic (Publish/Subscribe Messaging)
Security Realms
Introduction to Security Realms
Users
Groups
Security Roles
Security Policies
SSL
Secure socket layer
Certificates
One-Way SSL
Two-way SSL
Configure SSL in weblogic
Performance and tunneling
Reset the Weblogic Admin user password
Unlocking a User Account
Why Application servers came into picture
Before 1990’s we don’t have Application server, we have only webserver was there so that time we use
only webserver to do all (ecommerce transactions).
Web server alone provides the online store's functionality. The Web server takes your request, then
passes it to a server-side program able to handle the request. The server-side program looks up the
pricing information from a database or a flat file. Once retrieved, the server-side program uses the
information to formulate the HTML response, and then the Web server sends it back to your Web
browser.
It can one to one communication.
IE or Chrome
Webserver
Database
For one to one communication we cannot add any service in the Architecture, because of that only
Application server came in to picture means if you want to add any third party service you can easily add
that service or if you want to unplug you can do it very easily.
The Web server still delegates the response generation to a script. However, you can now put the
business logic for the pricing lookup onto an application server. With that change, instead of the script
knowing how to look up the data and formulate a response, the script can simply call the application
server's lookup service. The script can then use the service's result when the script generates its HTML
response.
In this scenario, the application server serves the business logic for looking up a product's pricing
information. That functionality doesn't say anything about display or how the client must use the
information. Instead, the client and application server send data back and forth. When a client calls the
application server's lookup service, the service simply looks up the information and returns it to the
client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far
more reusable between applications. A second client, such as a cash register, could also call the same
service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not
reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's
model, the Web server handles HTTP requests by replying with an HTML page while the application
server serves application logic by processing pricing and availability requests.
Webserver:
A Web server exclusively handles HTTP/HTTPS requests. It serves content to the web using
HTTP/HTTPS protocol.
A webserver you can say it’s a computer program or software that serves the webpage(static/dynamic)
using http over the world
Web Server is designed to serve HTTP Content.
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds
with an HTTP response, such as sending back an HTML page.
IIS : ASP (.NET)
Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
Application Server
An application server serves business logic to application programs through any number of protocols,
possibly including HTTP. The application program can use this logic just as it would call a method on an
object. In most cases, the server exposes this business logic through a component API, such as the EJB
(Enterprise JavaBean) component model found on Java EE (Java Platform, Enterprise Edition)
application servers.
WAS: EJB
JBoss: EJB
WebLogic Application Server: EJB
Diff b/w Application Server and WebServer
Web-server
Application-server
A webserver you can say it’s a computer
Application server is much more than serving
program or software that serves the
static/dynamic webpages.
webpage(static/dynamic) using http over the
It provides better performance tuning option.
world
It provides more security options.
Web Server is designed to serve HTTP
It provides scalability high availability which
Content.
webserver doesn’t provide.
A Web server handles the HTTP protocol.
Ex:Weblogic server,wespeare ,jboss
When the Web server receives an HTTP
request, it responds with an HTTP response,
such as sending back an HTML page.
Ex: Apache
Introduction to weblogic server:
Weblogic server introduced by weblogic in 1995.
BEA systems Acquired Weblogic server in 1998.
Oracle has Acquired Weblogic server in 2008.
WebLogic is a server software application that runs on a middle tier, between back-end databases and
related applications and browser-based thin clients. WebLogic is a leading e-commerce online
transaction processing (OLTP) platform, developed to connect users in a distributed computing
environment and to facilitate the integration of mainframe applications with distributed corporate data
and applications.
WebLogic server is based on Java 2 Platform, Enterprise Edition (J2EE), the standard platform used to
create Java-based multi-tier enterprise applications. J2EE platform technologies were developed
through the efforts of BEA Systems and other vendors in collaboration with the main developer, Sun
Microsystems. Because J2EE applications are standardized modules, WebLogic can automate many
system-level tasks that would otherwise have demanded programming time.
The main features of WebLogic server include connectors that make it possible for any legacy
application on any client to interoperate with server applications, Enterprise JavaBean (EJB)
components, resource pooling, and connection sharing that make applications very scalable. An
administration console with a user interface makes management tasks more efficient and features such
as Secure Sockets Layer (SSL) support for the encryption of data transmissions, as well as authentication
and authorization mechanisms make applications and transactions secure.
Diff b/w WLS Versions (8x,9.x, 10.x and 12c):
WLS 8.x
-
-
-
In wls 8.x, all the jms details
will be present in the same
config.xml.
In wls 8.x we don't have
concept of JMS modules and
Subdeployment.
In wls 8.x, we have queues,
topics are separately
In WLS 8.x we don’t have
LOCK & EDIT feature.
In wls 8.x we don't have
update application feature,
if you want to redeploy you
have to delete and deploy
WLS 9.x and 10.x
-
-
In wls 9. x/10.x it will be partly
maintained in config.xml and a
separate xml files in
domain/config/jms folders for
each jms module.
In wls 10.x they are clubbed inside
a JMS module.
In wls WL 9&10 we have LOCK &
EDIT feature.
From 9.x we have update feature
available.
In wls 9.x, server gets into ADMIN
mode, if deployment fails.
WLS12c
-
-
-
-
JDK version 7 or higher (1.7) is
recommended to install
WebLogic 12.1.2.
In wls 12c Dynamic Cluster
Support(dynamic cluster for a
highly scalable systems).
In wls 12c WebLogic Server
adds support for Oracle
Database 12c.
JMS enhancements(Supports
clustered targeted JMS Servers
for providing high availability
eliminating the need to
configure many JMS resources
for every single server)
-
application.
In 8.x sever never comes-up,
if even one of the
deployment fails
-
In wls 12c to apply patches in
WebLogic has changed from
the tool from BSU(BEA smart
update) to OPATCH.
Installation Guide
Diff ways we are going to install weblogic server like GUI it’s an general way just clicking next –next
process and command mode installation and silent mode installation, for silent mode of installation we
have to prepare one silent.xml file and we have to execute like below
./wls.bin –mode=silent.xml /root/harish/silent.xml
In 64bit operating systems we are going use generic.jar weblogic file ,for installing .jar file we use below
command.
GUI mode:
PATH=$JAVA_HOME/bin:$PATH; export PATH
java -jar wls1036_generic.jar
64-Bit Platforms Using a 64-Bit JDK:
JAVA_HOME=path_to_64-bit_JDK; export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH; export PATH
(UNIX or Linux only) Include the -d64 flag in the installation command when using a 32/64-bit hybrid JDK
(such as for the HP-PA, HPIA, and Solaris64 platforms). For example, if installing in graphical mode using
the Package installer:
java -d64 -jar wlsversion_generic.jar
Run the java -version command (or java -d64 -version command on UNIX or Linux platforms using a
32/64-bit hybrid JDK) to ensure that your JAVA_HOME refers to a 64-bit JDK.
If you are using the Sun 64-bit JDK, use the following command to install WebLogic Server:
java -Xmx1024m -jar wlsversion_generic.jar
Command Mode Installation (in Linux)
Installing Weblogic server in Linux machine
Go to the particular directory
To run file you have to use the below format
./ wls1035_oepe111172_linux32.bin –mode=console
Click Next
Click Next
Click 3
Write exit .
Silent Mode Installation
History of Weblogic Domain:
Weblogic server Domain:
A WebLogic Server administration domain is a logically related group of Java components. A domain
includes a special WebLogic Server instance called the Administration Server, which is the central point
from which you configure and manage all resources in the domain. Usually, you configure a domain to
include additional WebLogic Server instances called managed servers. You deploy Java components,
such as Web applications, EJBs, and Web services, and other resources to the managed servers and use
the Administration Server for configuration and management purposes only.
Command Mode Installation (Linux)
To create Weblogic domain
Go to below path
/root/Oracle/Middleware/wlserver_10.3/common/bin
Run ./config.sh
What Is the Administration Server
The Administration Server operates as the central control entity for the configuration of the entire
domain. It maintains the domain's configuration documents and distributes changes in the configuration
documents to managed servers. You can use the Administration Server as a central location from which
to monitor all resources in a domain.
Each WebLogic Server domain must have one server instance that acts as the Administration Server.
To interact with the Administration Server, you can use the Oracle WebLogic Server Administration
Console.
Managed Servers
Managed servers host business applications, application components, Web services, and their
associated resources. To optimize performance, managed servers maintain a read-only copy of the
domain's configuration document. When a managed server starts up, it connects to the domain's
Administration Server to synchronize its configuration document with the document that the
Administration Server maintains.
Cluster Managed Servers:
For production environments that require increased application performance, throughput, or high
availability, you can configure two or more Managed Servers to operate as a cluster.
A cluster is a collection of multiple WebLogic Server server instances running simultaneously and
working together to provide increased scalability and reliability.
In a cluster, most resources and services are deployed identically to each Managed Server (as opposed
to a single Managed Server), enabling failover and load balancing. A single domain can contain multiple
WebLogic Server clusters, as well as multiple Managed Servers that are not configured as clusters.
The key difference between clustered and non-clustered Managed Servers is support for failover and
load balancing. These features are available only in a cluster of Managed Servers.
Domain Creation Using Pack & Unpack Commands
The pack and unpack commands provide a simple, one-step method for creating Weblogic domains and
templates from the command line. The pack and unpack commands are available in the \common\bin
subdirectory of the product installation directory.
Pack
The pack command creates a template archive (.jar) file that contains a snapshot of either an entire
domain or a subset of a domain. You can use a template that contains a subset of a domain to create a
Managed Server domain directory hierarchy on a remote machine.
The below path u can find the pack.sh command
/root/Oracle/Middleware/wlserver_10.3/common/bin
Below is the command to do pack a domain
./pack.sh -domain=/root/Oracle/Middleware/user_projects/domains/Production_domain/ template=/root/Oracle/Middleware/user_templates/Production_domain.jar -managed=true template_name="Production domain for horizontal domain "
Check the below location jar is exists are not
/root/Oracle/Middleware/user_templates -------Production_domain.jar
Unpack
Creates a full domain or a subset of a domain used for a Managed Server domain directory on a remote
machine. You may use unpack only with a template compatible with your current installation.
A domain template provided by BEA and packaged with your current installation
A domain template created using the Domain Template Builder or WLST Offline
A domain template created using the pack command
Below is my .jar location
/root/Oracle/Middleware/user_templates
Now i am going to unpack command location
/root/Oracle/Middleware/wlserver_10.3/common/bin
Below is the command for unpack
./unpack.sh -template=/root/Oracle/Middleware/user_templates/Production_domain.jar domain=/root/Oracle/Middleware/user_projects/domains/Production_domain
Now i have done unpack
Start & Stop Servers
Start & Stop Weblogic Server (win/Linux)
For starting the Admin server in the backend
/root/Oracle/Middleware/user_projects/domains/Production_domain/bin
To start Admin server ---- ---./startWebLogic.sh
To stopping Admin server & Manage servers
ps -ef|grep weblogic
Admin server processid.txt
Kill -9 3608
Start & Stop Manage Servers
To start Manage servers-----./startManagedWebLogic.sh MS1 (Manage server name)
To start Manage servers-----./stopManagedWebLogic.sh MS1 (Manage server name)
Ps –ef |grep weblogic
You will find java process id’s
process id's.txt
Kill -9 3608(process id)
History of Boot.properties
A boot identity file contains the user credentials for starting and stopping an instance of WebLogic
Server. An administration server or managed server can refer to this file for user credentials instead of
prompting at the command line to provide them. Because the credentials are encrypted, using a boot
identity file is more secure than storing plain text credentials in a startup or shutdown script.
If you choose Development Mode when creating a domain by using the Configuration Wizard, a boot
identity file is automatically created for the administration server.
If you use Node Manager to start managed servers rather than running start scripts manually, you do
not need to create boot identity files for them. Node Manager creates its own boot identity files and
stores them under each server's directory in the data/nodemanagersubdirectory
After you install Weblogic in production mode while starting the servers you need to give username and
password each time you will start the Weblogic ./startWebLogic like below:
******************************************
< Dec 13, 2013 12:55:47 AM IST>
< Dec 13, 2013 12:55:48 AM IST>
*********************************************
To overcome this problem we have another way to configure the boot.preperties file.
Configure boot.properties
Step: 1
Create security folder inside the Admin server directory like below.
Go to the below folder
$/root/Oracle/Middleware/user_projects/Domain/Production_domain/servers/Adminserver
$mkdir security
After creating the security folder go to inside that folder and create the boot.properties file
$cd security
$vi boot.properties
Now the editor will open then enter i(I for insert) then write
username=weblogic
password=weblogic1
Now click Esc button in the keyboard and :wq! And enter.
Now boot.properties are created inside the security folder.
Step2:
Restart the Admin server this time server won’t ask username and password.
History of NodeManager
Node Manager is a utility that runs as separate process from Oracle WebLogic Server and allows you
to perform common operations for a Managed Server, regardless of its location with respect to its
Administration Server. While use of Node Manager is optional, it provides valuable benefits if your
WebLogic Server environment hosts applications with high-availability requirements.
If you run Node Manager on a machine that hosts Managed Servers, you can start and stop the
Managed Servers remotely using the Administration Console or the command line.
Node Manager can also automatically restart a Managed Server after an unexpected failure.
Types of NodeManager
Java-based node manager
Runs with in JVM (Java Virtual Machine) Process and more secure than script-based node manager.
Configuration for java-based node manager is stored in nodemanager.properties
Script-based node manager
Script-based node manager – is available for Linux and UNIX systems only and is based on shell script.
Configure NodeManager
History of Cluster
Cluster consists of multiple server instances running simultaneously and working together to provide
increased scalability and reliability.
A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute
a cluster can run on the same machine, or be located on different machines.
You can increase a cluster’s capacity by adding additional server instances to the cluster on an existing
machine, or you can add machines to the cluster to host the incremental server instances. Each server
instance in a cluster must run the same version of WebLogic Server.
Cluster Relate to a weblogic Domain
A cluster is part of a particular WebLogic Server domain.
A domain is an interrelated set of WebLogic Server resources that are managed as a unit.
A domain includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a
combination of clustered and non-clustered instances. A domain can include multiple clusters.
In each domain, one WebLogic Server instance acts as the Administration Server—the server instance
which configures, manages, and monitors all other server instances and resources in the domain.
Each Administration Server manages one domain only. If a domain contains multiple clusters, each
cluster in the domain has the same Administration Server.
All server instances in a cluster must reside in the same domain; you cannot “split” a cluster over
multiple domains. Similarly, you cannot share a configured resource or subsystem between domains.
EX:
If you create a JDBC connection pool in one domain, you cannot use it with a server instance or cluster
in another domain. (Instead, you must create a similar connection pool in the second domain.)
Benefits of Clustering
Scalability
The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to
meet demand. You can add server instances to a cluster without interruption of service—the application
continues to run without impact to clients and end users.
High-Availability
In a WebLogic Server cluster, application processing can continue when a server instance fails. You
“cluster” application components by deploying them on multiple server instances in the cluster—so, if a
server instance on which a component is running fails, another server instance on which that
component is deployed can continue application processing.
Types of Cluster’s
Firstly cluster is nothing but group of manage servers, this manage servers we are configuring in two
different ways
Vertical Cluster
Vertical Cluster is nothing but group of manage server are configured in the same machine.
Configure Vertical Cluster
Step1: Login to the weblogic console
Take Lock & Edit session and create new cluster
Name=Cluster
Messaging Mode=Unicast or Multicast (as per your requirment)
Click OK
Click on the cluster (which u created)
Click on the servers
Click on Add
Select the servers and finish.
Horizontal Cluster
Horizontal Cluster is nothing but group of manage servers are configured in the different machines.
Configure horizontal Cluster
Horizontal cluster mean –Multiple manage servers in multiple Machines
Step-1:
Here I have two vm’s –
192.168.157.130
192.168.157.131
Now I am creating new Domain in Machine-A(192.168.1.130)
Login in to Machine-A via putty
Step-2:
Create new Domain
Domain name =Production_domain
After creating the domain start the Admin server.
/root/Oracle/Middleware/user_projects/domain/Production_domain/bin
./startWeblogic.sh
Started Admin server
Step-3:
Login with the weblogic and password.
Click the servers
Step-4:
Create servers
Create MS1, MS2, MS3 and MS4 like below.
MS1 and MS2 give Machine-A ip address
MS3 and MS4 give Machine-B ip address
Manage server Name
IP Address
PORT
MS1
MS2
MS3
MS4
7004
7004
7005
7006
192.168.157.130
192.168.157.130
192.168.157.131
192.168.157.131
After creating manager server look like the above.
Step-5:
Create Machine in the Weblogic console
Click on the machines in the and create 2 machines
Name=Machine-A
Click next
Type=Plain (because we are not using ssl certificates)
Listen Address=192.168.157.130
Now Create Machine B
Click next
Type=Plain (because we are not using ssl certificates)
Listen Address=192.168.157.131
Step-6:
Now add manage servers to machines.
Means which manage server belongs to which machine
Manage-server
Machine
MS1
MS2
MS3
MS4
Machine-A
Machine-A
Machine-B
Machine-B
Scroll and select
IP-address
192.168.157.130
192.168.157.130
192.168.1.131
192.168.1.131
port
7003
7004
7005
7006
Now machines are configured.
Step-7:
Now create cluster
Name=Horizontal_cluster
Messaging mode=Unicast
Horizontal cluster is created.
Now add all manage server in to Cluster
Manage server
MS1
MS2
Ms3
Ms4
Cluster
Horizontal-Cluster
Horizontal-Cluster
Horizontal-Cluster
Horizontal-Cluster
Machine
Machine-A
Machine-A
Machine-B
Machine-B
Step-8:
Now add the cluster address in the Horizontal_Cluster>General
Ip-address
192.168.157.130
192.168.157.130
192.168.157.131
192.168.157.131
Port
7003
7004
7005
7006
Select the Algorithm type: round-robin (default) ---select whatever you want
Cluster Address: 192.168.157.130:7003,192.168.157.130:7004,192.168.157.130:7005,
192.168.157.130:7006
Number of servers in cluster Address: 4
Click save.
Click on the Replication tab
Cross-Cluster Replication Type: WAN(Asynchronous)HTTP Session State Replication
Remote Cluster Address: 192.168.157.130:7003,192.168.157.130:7004,192.168.157.130:7005,
192.168.157.130:7006
Click saves.
Click on Active changes.
Now we have done all configurations in the console
1---Created manage servers
2---Created machines
3---Created cluster
Now I am going to pack this entire domain. Before packing the domain stop all server .
Shutdown the servers.
Step-9:
Prepare the pack and unpack commands:
Run pack command in machine-A(because we have domain in machine-A)
Run unpack command in machine-B(We want same domain in machine-B)
./pack.sh -domain=/root/Oracle/Middleware/user_projects/domains/Production_domain/ template=/root/Oracle/Middleware/user_templates/Production_domain.jar -managed=true template_name="Production domain for horizontal cluster "
./unpack.sh -template=/root/Oracle/Middleware/user_templates/Production_domain.jar domain=/root/Oracle/Middleware/user_projects/domains/Production_domain
Run setDomainEnv.sh
Go to the root\Oracle\Middleware\wlserver-10.3\common\bin\
pack.sh
Run the pack.sh command
After packing the domain you will able to see above success message.
Domain is packed in to the user_templates folder with the Production.jar format.
Step-10:
Now I am going to send .jar file to machine-B location via win-scp
Step-11:
Go to machine-B(because we are going to unpack .jar file in machine)
Go to the /root/Oracle/Middleware/wlserver_10.3/Common/bin
Run the unpack command.
After unpacking the Domain you will able to see the above success message.
Now we have done pack the domain in machine-A and unpacking in machine-B.
Step:
1) Now start the weblogic server in the machine-A(192.168.157.130) by using ./startweblogic.sh
2) After starting the Adminserver lunch the weblogic console http://192.168.157.130:7001/console
3) Run MS3(manage server) in machine –B(192.168.157.131) by using
./startmanagedweblogic.sh Ms3 http://192.168.157.130:7001
Starting the MS3 server in Machine-B
Now see MS3 server is going to running mode.
Step-12:
Now just refresh the Admin server.
MS3 is going to running mode in the console.
The same way you can remaining manage server
MS1 and MS2 in Machine-A
MS3 and MS4 in Machine-B
Unicast & Multicast
Unicast and Multicast are the messaging modes in weblogic server cluster.
When servers are in a cluster, these member servers communicate with each other by sending
heartbeats and indicating that they are alive. For this communication between the servers, either
unicast or multicast messaging is used
To use multicast messaging, hardware configuration and support for multicast packets is required.
Unicast does not have this requirement, which is why using unicast in latest versions is recommended.
Unicast : In the Unicast messaging mode Cluster group members are chosen their group leader(the
senior manage server),only those group leaders communicate with the servers among the group and
these leaders notify each other about the availability of all the other servers.
EX: We have 6 manage server in two cluster groups, then in each cluster group the manage servers are
chose the leader, now the remaining manage server are send heartbeat(alive status) signals to the
leader in each group.
If manage server not sent heartbeat signal 10 interval (10sec=1intraval) the group leader will decide that
the manager server got down.
Multicast: Multicast messaging is used, it is a one-to-many communication, and every server sends
the notification/heartbeat/multicast packet to each other.
Multicast IP address in the range 224.0.0.0 – 239.255.255.255
EX: each and every manager server will receive the hert beat signal to other manager server.Heart beat
is nothing but it is a multicast address and the port number along with the manager server name.
Load Balancing in a Cluster
Failover and Replication in a Cluster
WebLogic Server Detects Failures
WebLogic Server instances in a cluster detect failures of their peer server instances by monitoring:
Socket connections to a peer server
Regular server heartbeat messages
WebLogic Server Heartbeat
If clustered server instances do not have opened sockets for peer-to-peer communication, failed servers
may also be detected via the WebLogic Server heartbeat. All server instances in a cluster use multicast
or unicast to broadcast regular server heartbeat messages to other members of the cluster.
Each heartbeat message contains data that uniquely identifies the server that sends the message.
Servers broadcast their heartbeat messages at regular intervals of 10 seconds. In turn, each server in a
cluster monitors the multicast or unicast address to ensure that all peer servers’ heartbeat messages are
being sent.
If a server monitoring the multicast or unicast address misses three heartbeats from a peer server (i.e., if
it does not receive a heartbeat from the server for 30 seconds or longer), the monitoring server marks
the peer server as “failed.” It then updates its local JNDI tree, if necessary, to retract the services that
were hosted on the failed server.
Replication and Failover for Servlets and JSPs
To support automatic replication and failover for servlets and JSPs within a cluster, Weblogic Server
supports two mechanisms for preserving HTTP session state:
Hardware load balancers
For clusters that use a supported hardware load balancing solution, the load balancing hardware simply
redirects client requests to any available server in the WebLogic Server cluster. The cluster itself obtains
the replica of the client’s HTTP session state from a secondary server in the cluster.
Proxy plug-ins
In clusters that utilize Web servers with WebLogic proxy plug-ins, the proxy plug-in handles failover
transparently to the client. If a server fails, the plug-in locates the replicated HTTP session state on a
secondary server and redirects the client’s request accordingly.
HTTP Session State Replication
Weblogic Server uses two methods for replicating HTTP session state across clusters:
In-memory replication
Using in-memory replication, WebLogic Server copies a session state from one server instance to
another. The primary server creates a primary session state on the server to which the client first
connects, and a secondary replica on another WebLogic Server instance in the cluster. The replica is kept
up-to-date so that it may be used if the server that hosts the servlet fails.
JDBC-based persistence
In JDBC-based persistence, WebLogic Server maintains the HTTP session state of a servlet or JSP using
file-based or JDBC-based persistence.
Weblogic Deployments
Generally we get following types of files to deploy
1) .war
2) .ear
3) .rar
4) .jar
5) .sar
Note: .ear = .war + .jar
In the above formats we cannot directly deploy .jar files in the server, but we can replace.jar which
already deployed. Some important file we get in deployment bundle.
.war contain
—–> META-INF/MANIFEST.MF –> Version info etc
—–>WEB-INF/web.xml
—> weblogic.xml (optional)
—–> APP-INF/application.xml (optional)
—-> weblogic-application.xml (optional)
Web.xml is called DD (deployment descriptor). It contains details of classes required and order of their
deployment t etc.
Note: .war can be deployed anywhere like web-logic server, web-sphere, Glass-fish etc. For
deployment on WL, there may be one more optional file
weblogic.xml
DD for .ear is application.xml (optional)
If a value is defined in both web.xml and weblogic.ml, then the value in web.xml will be taken
into consideration.
An installation guide (IG) or deployment guide is provided by developer to tell if files have to be
deployed in any specific order.
Modes of Deployments
In the weblogic we can deploy Applications in three modes
Stage
NO-Stage
External-Stage
Stage:
For the console deployments the default mode is STAGE when you deploy the application using stage
mode, the admin server copies the deployment files from the original deployment location of the
application on the admin server to each target server's stage directory.
For example, if you have a distributed environment, 3 managed servers in a cluster on 3 different
machines, and when a web application is deployed on the cluster, the admin server copies the
deployment files to the managed server/stage directory.
This mode is most commonly used. This is advantageous because when there is a network outage and
the managed servers are not able to communicate with the admin server, the managed servers still have
the deployment files so the application will be available.
Stage mode should only be used when the application to be deployed is not too large. It gives an
overhead in the production environment to copy huge application on each machine.
Syntax Command line deployment:
java weblogic.Deployer -adminurl 192.168.1.104:8001 -user weblogic -password weblogic -name
WorkManager1 -stage -targets Cluster1 -deploy WorkManager1
Admin Console deployment:
When you deploy an application to the cluster, stage mode is used by default. When you deploy the
application to the cluster, a stage directory will be created in the domain/server/managed server
directory. Inside the stage folder, the directory with the application name will be created. The whole
application resides in this. This local copy will be used by the managed servers to run the application.
Every time you redeploy the application, this local copy on every target server is updated with new
changes. Using staging mode only makes sense when there is a distributed environment. When all the
servers are in the same machine, the managed servers can use a shared copy of the application.
No-Stage
When no-stage deployment is used, the admin server does not copy the application to the directory of
every server. The servers have to access the application from a shared location. So if no stage option is
used for deployment, the stage directory is ignored.
Syntax to deploy application in no-stage mode:
java weblogic.Deployer -adminurl 192.168.1.104:8001 -user weblogic -password weblogic -name
mydeploymentname -targets MyCluster -nostage -deploy c:\localfiles\myapp.ear
If the application is too huge, it is better to use no-stage so that the overhead while deployment
decreases.
Even if no-stage mode is used, it does not mean that the server does not have the application local copy
with it. The application temporary copy is created and saved in the tmp folder of the server for easy and
quick access of the application.
External stage
External stage deployment is similar to stage mode deployment. But in this, admin server is not
responsible to copy the deployment files to the target servers. This should be done manually by the
user.
Steps:
Create a stage folder in each target server directory.
Inside the stage folder, create another folder by the name of the application that will be
deployed. For e.g.: MyWebApp
Then copy the deployment files to the folder. Do this for each target server.
From the admin console, go to target server, -> Configuration -> Deployments. Change the
Staging mode to external stage in the drop down list.
Enter the below command in the command prompt:
java weblogic.Deployer -adminurl 192.168.1.104:8001 –username weblogic -password weblogic external_stage MyCluster -name web-app -deploy \home\Apps\web-app
External stage mode is the least common mode of application deployments. This mode is used when the
application size is very huge and the time of application deployment needs to be saved.
When you need application local copies on every server and the application size is very huge, you cannot
use no-stage mode and stage mode which takes lot of time. You can use external stage.
Types of Deployments
Console Mode deployments
Step1:
Take Lock & Edit session and on the deployments.
Step2:
Click on the Install button
Step3:
Click on upload your files option.
Step4:
Browse the deployable file from the choose option
Click Next
Step5:
Click Next-Next
Step6:
Select the targets .
Click Next-Next-Finish
Now the application is deployed .
Step7:
Click on Active changes.
Go to deployments
See the application is deployed and it’s in prepared state ,now I am going to start the application by
using the start application request
Step8:
Now the Application is deployed successfully .
Side by Side deployments:
Production redeployment of application/ versioning/ side by side deployment
We need versioning for updating the application in production on runtime. The sessions which are
already logged in will be using the previous version of the application and the new sessions created will
use the new version of application.
Deploying:
java weblogic.Deployer -appversion 1 -adminurl http://192.168.1.104:7001 -username weblogic password weblogic1 -deploy -name ATM1.1 -source \root\…\ -targets ClusterA
Redeploying:
bin>java weblogic.Deployer -appversion 2 -adminurl http://192.168.1.104:7001 -username weblogic password weblogic1 -redeploy -name ATM1.2 -source \root\...\ -retiretimeout 120
WLST Deployment:
java weblogic.WLST benifits.py
benifits.py
Weblogic Server JDBC Resources
The Administration Console provides an interface to the tools that allow you to configure and manage
WebLogic Server features, including JDBC (database connectivity with Java). For most JDBC
administrative functions, which include creating, managing and monitoring connectivity, systems
administrators use the Administrative Console or the command-line interface. Application developers
may want to use the JDBC API.
Datasource:
In WebLogic Server, you configure database connectivity by adding data sources to your WebLogic
domain. WebLogic JDBC data sources provide database access and database connection management.
Each data source contains a pool of database connections that are created when the data source is
created and at server startup. Applications reserve a database connection from the data source by
looking up the data source on the JNDI tree or in the local application context and then calling
getConnection(). When finished with the connection, the application should call connection.close() as
early as possible, which returns the database connection to the pool for other applications to use.
JDBC data source names are used to identify the data source within the WebLogic domain.
Connection Pool:
Each JDBC data source has a pool of JDBC connections that are created when the data source is
deployed or at server startup.
Applications use a connection from the pool then return it when finished using the connection.
Connection pooling enhances performance by eliminating the costly task of creating database
connections for the application.
JDBC Driver:
When creating a JDBC data source using the Administration Console, you are prompted to select a JDBC
driver.
The Administration Console provides the driver class name and helps you construct the URL as required
by the driver.
The driver you select must be in the classpath on all servers on which you intend to deploy the data
source. Some but not all JDBC drivers listed in the Administration Console are shipped with WebLogic
Server
Third-party JDBC drivers:
Oracle Thin Driver (XA and non-XA)
Sybase jConnect
PointBase
WebLogic Type 4 JDBC Drivers from DataDirect for the following database
management systems:
DB2
Informix
Microsoft SQL Server
Oracle
Sybase
All of these drivers are referenced by the weblogic.jar manifest file and do not need to be explicitly
defined in a server's classpath.
Generic Data source:
Statement Cache Algorithms
The Statement Cache Type (or algorithm) determines which prepared and callable statements to store in
the cache for each connection in a data source.
LRU (Least Recently Used)
Fixed
LRU (Least Recently Used):
When you select LRU (Least Recently Used, the default) as the Statement Cache Type, WebLogic
Server caches prepared and callable statements used on the connection until the statement cache
size is reached. When an application calls Connection.prepareStatement(), WebLogic Server checks to
see if the statement is stored in the statement cache. If so, WebLogic Server returns the cached
statement (if it is not already being used). If the statement is not in the cache, and the cache is full
(number of statements in the cache = statement cache size), Weblogic Server determines which
existing statement in the cache was the least recently used and replaces that statement in the cache
with the new statement.
The LRU statement cache algorithm in WebLogic Server uses an approximate LRU scheme.
Fixed:
When you select FIXED as the Statement Cache Type, WebLogic Server caches prepared
and callable statements used on the connection until the statement cache size is reached.
When additional statements are used, they are not cached.
With this statement cache algorithm, you can inadvertently cache statements that are
rarely used. In many cases, the LRU algorithm is preferred because rarely used
statements will eventually be replaced in the cache with frequently used statements.
Statement Cache Size:
The Statement Cache Size attribute determines the total number of prepared and callable
statements to cache for each connection in each instance of the data source. By caching
statements, you can increase your system performance. However, you must consider how
your DBMS handles open prepared and callable statements. In many cases, the DBMS will
maintain a cursor for each open statement. This applies to prepared and callable
statements in the statement cache. If you cache too many statements, you may exceed
the limit of open cursors on your database server.
EX:
If you have a data source with 10 connections deployed on 2 servers, if you set the
Statement Cache Size to 10 (the default), you may open 200 (10 x 2 x 10) cursors on
your database server for the cached statements.
Grid link Data source:
A single GridLink data source provides connectivity between WebLogic Server and an Oracle
Database service targeted to an Oracle RAC cluster. It uses the Oracle Notification Service
(ONS) to adaptively respond to state changes in an Oracle RAC instance. An Oracle
Database service represents a workload with common attributes that enables administrators
to manage the workload as a single entity. You scale the number of GridLink data sources
as the number of services increases in the data base, independent of the number of nodes
in the cluster.
Fast Connection Failover:
A GridLink data source uses Fast Connection Failover and responds to Oracle RAC events
using ONS. This ensures that the connection pool in the GridLink data source contains valid
connections (including reserved connections) without the need to poll and test connections.
Runtime Connection Load Balancing:
GridLink data sources provide load balancing in XA and non-XA environments.
GridLink data sources use runtime connection load balancing to distribute connections to Oracle RAC
instances based on Oracle FAN events issued by the database.
This simplifies data source configuration and improves performance as the database drives load
balancing of connections through the GridLink data source, independent of the database topology.
Runtime Connection Load Balancing allows WebLogic Server to:
Adjust the distribution of work based on back end node capacities such as CPU, availability, and
response time.
React to changes in Oracle RAC topology.
Manage pooled connections for high performance and scalability.
Graceful Handling for Oracle RAC Outages
A GridLink data source provides graceful handling for the planned and unplanned shutdown of an Oracle
RAC service:
For planned shutdowns, the data source allows in-progress transactions to complete before closing
connnections. New Requests are load balanced to active Oracle RAC instances.
For unplanned shutdowns, the data source rolls back in-progress transactions and closes the
connections.
New Requests are load balanced to active Oracle RAC instances.
XA Affinity
XA Affinity for global transactions ensures all the data base operations for a global transaction
performed on an Oracle RAC cluster are directed to the same Oracle RAC instance. The first connection
request for an XA transaction is load balanced using RCLB and is assigned an Affinity context. All
subsequent connection requests are routed to the same Oracle RAC instance using the Affinity context
of the first connection.
Multi-Data source:
A multi data source can be thought of as a pool of data sources. Multi data sources are best used for
failover or load balancing between nodes of a highly available database system, such as redundant
databases or Oracle Real Application Clusters (RAC).
Multi Data Source Algorithm
Before you set up a multi data source, you need to determine the primary purpose of the multi data
source—failover or load balancing. You can choose the algorithm that corresponds with your
requirements.
Failover:
The Failover algorithm provides an ordered list of data sources to use to satisfy connection requests.
Normally, every connection request to this kind of multi data source is served by the first data source in
the list. If a database connection test fails and the connection cannot be replaced, or if the data source is
suspended, a connection is sought sequentially from the next data source on the list.
Load Balancing:
Connection requests to a load-balancing multi data source are served from any data source in the list.
The multi data source selects data sources to use to satisfy connection requests using a round-robin
scheme. When the multi data source provides a connection, it selects a connection from the data source
listed just after the last data source that was used to provide a connection. Multi data sources that use
the Load Balancing algorithm also fail over to the next data source in the list if a database connection
test fails and the connection cannot be replaced, or if the data source is suspended.
JMS
JMS is a standard API for accessing enterprise messaging systems. Specifically,
WebLogic JMS:
Enables Java applications sharing a messaging system to exchange messages. Simplifies application
development by providing a standard interface for creating, sending, and receiving messages.
https://blogs.oracle.com/soaproactive/entry/how_to_create_a_simple
ConnectionFactory:
A ConnectionFactory encapsulates connection configuration information, and enables JMS
applications to create a Connection. A connection factory supports concurrent use, enabling multiple
threads to access the object simultaneously. You can use the preconfigured default connection factories
provided by WebLogic JMS, or you can configure one or more connection factories to create
connections with predefined attributes that suit your application.
Default Connection factory’s:
weblogic.jms.ConnectionFactory ----XA (False)
weblogic.jms.XAConnectionFactory—XA(True)
Queue (Point-to-Point Messaging):
The point-to-point (PTP) messaging model enables one application to send a message to another.
PTP messaging applications send and receive messages using named queues.
A queue sender (producer) sends a message to a specific queue. A queue receiver (consumer) receives
messages from a specific queue.
Multiple queue senders and queue receivers can be associated with a single queue, but
an individual message can be delivered to only one queue receiver.
If multiple queue receivers are listening for messages on a queue, WebLogic JMS
determines which one will receive the next message on a first come, first serve basis. If
no queue receivers are listening on the queue, messages remain in the queue until a
queue receiver attaches to the queue.
Topic (Publish/Subscribe Messaging):
The publish/subscribe (pub/sub) messaging model enables an application to send a message to multiple
applications. Pub/sub messaging applications send and receive messages by subscribing to a topic. A
topic publisher (producer) sends messages to a specific topic. A topic subscriber (consumer) retrieves
messages from a specific topic.
Unlike with the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to
receive the same message. JMS retains the message until all topic subscribers have received it.
Introduction to Security Realms
A security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists
of a set of configured security providers, users, groups, security roles, and security policies.
A user must be defined in a security realm in order to access any WebLogic resources belonging to that
realm.
When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate
and authorize the user by checking the security role assigned to the user in the relevant security realm
and the security policy of the particular WebLogic resource.
Users
Users are entities that can be authenticated in a security realm, such as myrealm
A user can be a person, such as application end user, or a software entity, such as a client application, or
other instances of WebLogic Server.
As a result of authentication, a user is assigned an identity, or principal. Each user is given a unique
identity within the security realm. Users may be placed into groups that are associated with security
roles, or be directly associated with security roles.
When users want to access WebLogic Server, they present proof material (for example, a password or a
digital certificate) typically through a JAAS LoginModule to the Authentication provider configured in the
security realm.
If WebLogic Server can verify the identity of the user based on that username and credential, WebLogic
Server associates the principal assigned to the user with a thread that executes code on behalf of the
user.
Note: All user names and groups must be unique within a security realm.
Groups
Groups are logically ordered sets of users
Usually, group members have something in common. For example, a company may separate its sales
staff into two groups, Sales Representatives and Sales Managers. Companies may do this because they
want their sales personnel to have different levels of access to WebLogic resources, depending on their
job functions.
Managing groups is more efficient than managing large numbers of users individually.
EX: An administrator can specify permissions for 50 users at one time by placing the users in a group,
assigning the group to a security role, and then associating the security role with a WebLogic resource
via a security policy.
Note: All user names and groups must be unique within a security realm.
Security Roles:
A security role is a privilege granted to users or groups based on specific conditions Like groups, security
roles allow you to restrict access to WebLogic resources for several users at once. However, unlike
groups, security roles:
Are computed and granted to users or groups dynamically, based on conditions such as user
name, group membership, or the time of day.
Can be scoped to specific WebLogic resources within a single application in a WebLogic Server
domain (unlike groups, which are always scoped to an entire WebLogic Server domain).
Granting a security role to a user or a group confers the defined access privileges to that user or group,
as long as the user or group is "in" the security role. Multiple users or groups can be granted a single
security role.
Security Policies:
A security policy is an association between a WebLogic resource and one or more users, groups, or
security roles. Security policies protect the WebLogic resource against unauthorized access. A WebLogic
resource has no protection until you create a security policy for it. A policy condition is a condition under
which a security policy will be created. WebLogic Server provides a set of default policy conditions.
SSL: An Introduction
Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a
network connection to authenticate the other's identity and by encrypting the data exchanged between
the applications.
Authentication allows a server and optionally a client to verify the identity of the application on the
other end of a network connection. Encryption makes data transmitted over the network intelligible
only to the intended recipient.
WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL
connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs
schema in the connection URL, for example, https://myserver:7002.
WLS is by default configured with DemoIdentity and DemoTrust, we just need to enable SSL port under
General Tab of the Server and WLS will start listening over SSL on that port (7002).
Certificates
Private keys, digital certificates, and trusted certificate authorities establish and verify server identity.
SSL uses public key encryption technology for authentication. With public key encryption, a public key
and a private key are generated for a server.
The keys are related such that data encrypted with the public key can only be decrypted using the
corresponding private key and vice versa.
The private key is carefully protected so that only the owner can decrypt messages that were encrypted
using the public key.
The public key is embedded into a digital certificate with additional information describing the owner of
the public key, such as name, street address, and e-mail address.
A private key and digital certificate provide identity for the server.
An application participating in an SSL connection is authenticated when the other party evaluates and
accepts the application's digital certificate. Web browsers, servers, and other SSL-enabled applications
generally accept as genuine any digital certificate that is signed by a trusted certificate authority and is
otherwise valid.
One-Way SSL
One-way SSL, the server is required to present a certificate to the client but the client is not required to
present a certificate to the server. To successfully negotiate an SSL connection, the client must
authenticate the server but the server will accept any client into the connection. One-way SSL is
common on the Internet where customers want to create secure connections before they share
personal data. Often, clients will also use SSL to log on so that the server can authenticate them.
Two-way SSL
Two-way SSL (SSL with client authentication), the server presents a certificate to the client and the client
presents a certificate to the server. WebLogic Server can be configured to require clients to submit valid
and trusted certificates before completing the SSL connection.
Performance and tunneling
Reset the Weblogic Admin user password
Step1:
Shutdown all Managed Servers, Admin Server in the weblogic Domain.
Step2:
Run the below command to reset the Admin password after setting WLS environment variables.
$ cd /Oracle/Middleware/user_projects/Domains/mydomain/bin/
$ /.setDomainEnv.sh
$cd /Oracle/Middleware/user_projects/Domains/mydomain /security
cp DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift_bkp
java weblogic.security.utils.AdminAccount weblogic .
run the above command in the below example location
user_home\domains\my_domain\security>java weblogic.security.utils.AdminAccount newAdmin
newPassword .
The above command will create DefaultAuthenticatorInit.ldift file with new password on the same
location
Step3:
Run the below steps to re-create the AdminServer
$cd /Oracle/Middleware/user_projects/Domains/mydomain /servers/
mv Adminserver AdminServer_bkp
Step4:
Start the AdminServer manually for the first time.
$cd Oracle/Middleware/user_projects/Domains/mydomain /bin
./startWebLogic.sh
This time enter the username and new password manually when it prompts
If you want keep the same password for both AdminServer and NodeManager then do the below step.
Login Admin Console-->Lock and Edit-->Domain
Click on Security tab
Click on Advanced link
Update Node Manager Password and confirm it, then click Save
Click "Activate Changes"
Run the below steps for each NodeManager on all servers
cd $NM_HOME
mv nm_data.properties nm_data.properties_bkp
So it will create a new encryption data the Node Manager uses as a symmetric encryption key
nohup ./startNodeManager.sh &
Shutdown all the NodeManager and Admin server.
Create a boot.properties with below values on
$DOMAIN_HOME/servers/AdminServer/security/
username=weblogic admin user name
password=new password
Now you can bring up the AdminServer followed by Managed servers in the domain.
Unlocking a User Account
To unlock a locked user account on a managed server, a user with Admin privileges can use the following
command:
java weblogic.Admin -url 192.168.1.104:7001 -username weblogic -password weblogic1 -type
weblogic.management.security.authentication.UserLockoutManager -method clearLockout
lockedusername
You can also wait the time specified in the Lockout Duration attribute. The user account will be unlocked
after the specified time.
To unlock a user account using the Administration Console:
1. Expand the Monitoring-->Security tab for the server.
2. In the User table, click on the Details link for the user to be unlocked.
3. Click Unlock.
Errors:
1) Possible errors while creating multidaatasource
Failed to bind remote object (ClusterableRemoteRef(1478582895960188952S:192.168.157.130:Production_domain:MS1 null)/295
[weblogic.jdbc.common.internal.RemoteDataSource]) to replica aware stub at
myDataSource(ClusterableRemoteRef(1478582895960188952S:192.168.157.130:Production_domain:MS1 [1478582895960188952S:192.168.157.130:Production_domain:MS1/282, 1641020309091241343S:192.168.157.130:[7006,7006,-1,-1,-1,-1,-1]:Production_domain:MS4/282])/282
[weblogic.jdbc.common.internal.RemoteDataSource])
Resolution:
root cause for this kind of bind exceptions are becuase of duplicate entries or already existing entries
which are conflicting with each other while getting active and acquiring connections.
Make sure all the existing datasource Names and JNDI names are unique. If you find any JNDI name
duplicated then make sure to make it unique or use the already existing JNDI if it works and connects to
the same DB.
Once all are checked restart the managed server to re-initiate all datasources.In case if you are getting
this error in your weblogic log file its better to remove the faulty datasource and reconfigure freshly
post managed server restart to avoid errors.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 82 Language : en-US Tagged PDF : Yes Title : Weblogic Server Administration Author : Harish Creator : Microsoft® Word 2010 Create Date : 2014:12:25 23:53:42+05:30 Modify Date : 2014:12:25 23:53:42+05:30 Producer : Microsoft® Word 2010EXIF Metadata provided by EXIF.tools