PHYSICAL SERVERS VS. VIRTUAL MACHINES

Though visualization has become the new normal for businesses of all sizes, physical server infrastructures are still quite widespread. Do you think that the companies using traditional, physical server networks are wasting money? This post will show you why this is exactly the case! Let’s start with what we used to have when physical servers were the normal platform of choice. The architecture of a physical server is quite plain. Each server has its own hardware: memory, network, processing and storage resources. On this hardware the server operating system is loaded. From the OS you can then run the applications. Pretty straight-forward.

Physical Server	Virtual Infrastructure

With a virtual infrastructure you have the same physical server with all the resources but instead of the server operating system there’s a hypervisor, such as vSphere or Hyper-V loaded on it. The hypervisor is where you actually create your Virtual Machines. As you can see on the diagram, each VM has its own virtual devices – virtual CPU, virtual memory, virtual network interface cards and its own virtual disk. On top of this virtual hardware you load a guest operating system and then your traditional server applications.

The benefits of visualization are obvious: instead of having just one application per server you can now run several guest Operating Systems and a handful of applications with the same physical hardware. That’s right, visualization can bring you so much more for your money!

Hardware Independence and VM portability

So what enables a Virtual Machine to be portable across physical machines running the same hypervisor? As said, every Virtual Machine has its own virtual hardware. So the guest operating system loaded on a VM is only aware of this hardware configuration and not the physical server’s one. In other words, a VM is completely hardware independent. It means that the operation system installed on a VM is no longer tied up to certain hardware and you can easily move virtual machines from one physical server to another or even to another data center!

This makes the VMs are absolutely portable! You can copy it to a flash drive, you can bring it home and replicate it at your home lab, you can give it to a friend or send it to your clients! You can even replicate a virtual machine across WAN or across the Internet!

More goodies of virtual machines

We talked about one of the key features that visualization provides which is virtual machine portability that is possible thanks to hardware independence. It allows you to easily migrate a VM to any place you like: you can back it up and restore on another server, you can put it on your flash drive and run it on your home lab or workstation, or you can even take the VM to another site! But that’s not all! There’s a whole of useful features created by the Hardware independence and VM portability:

• vMotion is a VMware technology providing VM portability and hardware independence that allows migrating of a running VM from one server to another with no downtime for the end user!
• Distributed Resource Scheduler or DRS. This VMware technology enables balancing virtual infrastructure in the aspect of resource consumption. DRS can move a running VM from one host to another (by means of vMotion) in order to give it all the resources it needs to operate effectively.
• VMware High Availability or VMHA is an option that allows you to restore VMs from a failed server to another so that you’ll get it back running at no time.
• Distributed Power Management or DPM is another great VMware feature that can help you reduce your company’s energy bill! With this feature you can easily bring power consumption by the infrastructure under control. DPM consolidates VMs on fewer physical servers when resource consumption across the virtual infrastructure is low. All the servers that are not needed will be turned off in the meantime.
• Visualization makes Disaster Recovery way simpler as well. Thanks to the hardware independence once a VM inside your virtual infrastructure fails you can just run your backed up VMs on any server because the guest OS’s are no more tied up to particular hardware.

And this is just the top of the iceberg! Virtual machines have got much more great features that the traditional physical server-based infrastructure lacks. But in order to make maximum use of that great new functionality brought by visualization you should use the right tools for monitoring, managing and, of course, for data protection. Since virtual machines differ markedly from physical servers, the tools designed for the latter are no good for the former. It counts in particular for the backup.

Various GC Collectors

Collector	Function	Recommended for	How to enable
Serial Collector	Uses single thread for both minor and major collections. Simplest.	Single processor machines	-XX:+UseSerialGC
Parallel Collector (Throughput Collector)	Uses multiple threads for minor collection.	Multi processor machines, enterprise class applications	-XX:+UseParallelGC To enable Major parallel collection, add -XX:+UseParallelOldGC
CMS Collector (Concurrent Mark and Sweep Collector)	Mostly performs GC simultaneously along with Application	Applications that cannot tolerate longer GC pause times	-XX:+UseConcMarkSweepGC
G1 Collector	Strives to collect from Heap regions that have the most garbage	Most enterprise class applications. Through testing required before implementing.	–XX:+UseG1GC

Work Managers

Work Managers

1]. WebLogic Server allows you to configure how your application prioitizes the   

     execution of its work. 

2]. Based on rules you define and by monitoring actual runtime performance, WebLogic   

     Server can optimize the performance of your application and maintain service level  

     agreements. 

3].  You define the rules and constraints for your application by defining a Work Manger  

      and applying it either globally to WebLogic Server domain or to a specifi  

      application component.

4]. In WebLogic Server 9.0 there is a single thread pool, in which all types of work are  

     executed. WebLogic Server prioritizes work based on rules you define, and run-

     time metrics, including the actual time it takes to execute a request and the rate at

     which requests are entering and  leaving the pool.

5]. The common thread pool changes its size automatically to maximize

      throughput. The queue monitors throughput over time and based on history,

      determines whether to adjust the thread count. 

     For example, if historical throughput statistics indicate that a higher thread count  

     increased  throughput, WebLogic increases the thread count. Similarly, if statistics

     indicate that fewer threads did not reduce throughput, WebLogic decreases the  

     thread count. This new strategy makes it easier for administrators to allocate

     processing resources and manage performance, 

     avoiding the effort and complexity involved in configuring, monitoring, and tuning

      custom executes queues.

6]. Administrators can configure a set of scheduling guidelines and associate

     them with one or more applications, or with particular application components.

For example,

  

you  can associate one set of scheduling guidelines for one application, and another  

  set of guidelines for other application. At run-time, WebLogic Server uses these

  guidelines to assign  pending work and enqueued requests to execution threads.

7] .

Work Managers can be configured at the domain level, application level, and module level in one of the following configuration files:

• config.xml—Work Managers specified in config.xml can be assigned to any application, or application component, in the domain. You can use the Administration Console to define a Work Manager.
• weblogic-application.xml—Work Managers specified at the application level in can be assigned to that application, or any component of that application.
• weblogic-ejb-jar.xml or weblogic.xml—Work Managers specified at the component-level can be assigned to that component.
• weblogic.xml—Work Managers specified for a Web Application.

Work Manager Stanza

<work-manager>

<name>highpriority_workmanager</name>

   <fair-share-request-class>

      <name>high_priority</name>

      <fair-share>100</fair-share>

   </fair-share-request-class>

   <min-threads-constraint>

      <name>MinThreadsCountFive</name>

      <count>5</count>

</work-manager>

To reference the Work Manager listed above in the dispatch policy of a Web Application, add the below code into the Web Application's web.xml file:

Referencing the Work Manager in a Web Application

<init-param>

   <param-name>dispatch-policy</param-name>

   <param-value>highpriority_workmanager</param-value>

</init-param>

8]  To manage work in your applications, you define one or more of the following Work Manager 

     components:

• Fair Share Request Class:
• Response Time Request Class:
• Min Threads Constraint:
• Max Threads Constraint:
• Capacity Constraint
• Context Request Class:

• fair-share-request-class—Specifies the average percentage of thread-use time required to process requests.

For example, assume that WebLogic Server is running two modules. The Work Manager for ModuleA specifies a fair-share-request-class of 80 and the Work Manager for ModuleB specifies afair-share-request-class of 20.

During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and ModuleB, respectively.

• response-time-request-class—This type of request class specifies a response time goal in milliseconds. Response time goals are not applied to individual requests. Instaead, WebLogic Server computes a tolerable waiting time for requests with that class by subtracting the observed average thread use time from the response time goal, and schedules schedule requests so that the average wait for requests with the class is proportional to its tolerable waiting time.

For example, given that ModuleA and ModuleB in the previous example, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.

• context-request-class—This type of request class assigns request classes to requests based on context information, such as the current user or the current user's group.

• max-threads-constraint—This constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.

A max-threads-constraint can be defined in terms of a the availability of resource that requests depend upon, such as a connection pool.

A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.

• min-threads-constraint—This constraint guarantees a number of threads the server will allocate to affected requests to avoid deadlocks. The default is zero. A min-threads-constraint value of one is useful, for example, for a replication update request, which is called synchronously from a peer.

A min-threads-constraint might not necessarily increase a fair share. This type of constraint has an effect primarily when the server instance is close to a deadlock condition. In that case Then, however, it the constraint will cause WebLogic Server to schedule a request from a even if requests in the service class have gotten more than its fair share recently.

• capacity—This constrain causes the server to reject requests only when it has reached its capacity. The default is zero. Note that the capacity includes all requests, queued or executing, from the constrained work set. Work is rejected either when an individual capacity threshold is exceeded or if the global capacity is exceeded. This constraint is independent of the global queue threshold.

Java heap, Native memory and Process size

Java heap: 

This is the memory that the JVM uses to allocate java objects. The maximum value of java heap memory
is specified using the -Xmx flag in the java command line. If the maximum heap size is not specified, then the limit is decided by the JVM considering factors like the amount of physical memory in the machine and the amount of free memory available at that moment. It is always recommended to specify the max java heap value.

Native memory

This is the memory that the JVM uses for its own internal operations. The amount of native memory heap that will be used by the JVM depends on the amount of code generated, threads created, memory used during GC for keeping java object information and temporary space used during code generation, optimization etc. If there is a third party native module, it could also use the native memory. For example, native JDBC drivers allocate native memory.

The max amount of native memory is limited by the virtual process size limitation on any given OS and the amount of memory already committed for the java heap with -Xmxflag. For example, if the application can allocate a total of 3 GB and if the max java heap is 1 GB, then the max possible native memory is approximately 2 GB.

Process size: 

Process size will be the sum of the java heap, native memory and the memory occupied by the loaded
executables and libraries. On 32-bit operating systems, the virtual address space of a process can go up to 4 GB. Out of this 4 GB, the OS kernel reserves some part for itself (typically 1 - 2 GB). The remaining is available for the application.

JRockit JDK Release Numbering Scheme

Every JRockit JVM release comes with several Java versions. For example, JRockit JVM R28.0 comes with Java SE versions 5.0 and 6. A Java version can be compatible with multiple JRockit JVM releases.
The JRockit JDK release number consists of the following elements:

• The JRockit JVM release number (Rnn.nn.nn)
• The Java version (J2SE 5.0 or Java SE 6)

For example :


Oracle JRockit JDK 6 R28.0.0 indicates the 28.0.0 release of JRockit JVM used with Java SE 6; similarly, Oracle JRockit JDK 5.0 R28.0.0 indicates the 28.0.0 release of the JRockit JVM used with J2SE 5.0.

Weblogic Server Versions

Weblogic Server Versions

Weblogic Server Versions  ( As on date Jan-2015 )

WebLogic Server 12c Release 3 (12.1.3) - June 26, 2014

WebLogic Server 12c Release 2 (12.1.2) - July 11, 2013

WebLogic Server 12c Release 1 (12.1.1) - Dec 1, 2011

WebLogic Server 11gR1 PS5 (10.3.6) - February 26, 2012

WebLogic Server 11gR1 PS4 (10.3.5) - May 16, 2011

WebLogic Server 11gR1 PS3 (10.3.4) - January 15, 2011

WebLogic Server 11gR1 PS2 (10.3.3) - April 2010

WebLogic Server 11gR1 PS1 (10.3.2) - November 2009

WebLogic Server 11g (10.3.1) - July 2009

WebLogic Server 10.3 - August 2008

WebLogic Server 10.0 - March 2007

WebLogic Server 9.2

WebLogic Server 9.1

WebLogic Server 9.0 - November 2006

WebLogic Server 8.1-bea - July 2003

WebLogic Server 7.0 - June 2002

WebLogic Server 6.1

WebLogic Server 6.0 - file date March 2001 on an old CD

WebLogic Server 5.1 (code name: Denali) First version supporting hot deployment for applications (via command line)

WebLogic Server 4.0

WebLogic Tengah 3.1 - June 1998

WebLogic Tengah 3.0.1 - March 1998

WebLogic Tengah 3.0 - January 1998

WebLogic Tengah - November 1997

Apache Upgrade - 2.2 to 2.4

Apache Upgrade - 2.2 to 2.4

This document describes changes in server behavior that might require you to change your configuration or how you use the server in order to continue using 2.4 as you are currently using 2.2. To take advantage of new features in 2.4, see the New Features document.

This document describes only the changes from 2.2 to 2.4. If you are upgrading from version 2.0, you should also consult the 2.0 to 2.2 upgrading document.

§         Compile-Time Configuration Changes

§        Run-Time Configuration Changes

§        Misc Changes

§        Third Party Modules

§       Common problems when upgrading

Compile-Time Configuration Changes

The compilation process is very similar to the one used in version 2.2. Your old configure command line (as found in build/config.nice in the installed server directory) can be used in most cases. There are some changes in the default settings. Some details of changes:

·         These modules have been removed: mod_authn_default, mod_authz_default, mod_mem_cache. If you were using mod_mem_cache in 2.2, look at mod_cache_disk in 2.4.

·         All load balancing implementations have been moved to individual, self-contained mod_proxy submodules, e.g.mod_lbmethod_bybusyness. You might need to build and load any of these that your configuration uses.

·         Platform support has been removed for BeOS, TPF, and even older platforms such as A/UX, Next, and Tandem. These were believed to be broken anyway.

·         configure: dynamic modules (DSO) are built by default

·         configure: By default, only a basic set of modules is loaded. The other LoadModule directives are commented out.

·         configure: the "most" module set gets built by default

·         configure: the "reallyall" module set adds developer modules to the "all" set

Run-Time Configuration Changes

There have been significant changes in authorization configuration, and other minor configuration changes, that could require changes to your 2.2 configuration files before using them for 2.4.

Authorization

Any configuration file that uses authorization will likely need changes.

You should review the Authentication, Authorization and Access Control Howto, especially the section Beyond just authorization which explains the new mechanisms for controlling the order in which the authorization directives are applied.

Directives that control how authorization modules respond when they don't match the authenticated user have been removed: This includes AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, AuthzUserAuthoritative, and AuthzOwnerAuthoritative. These directives have been replaced by the more expressive RequireAny, RequireNone, and RequireAll.

Access control

In 2.2, access control based on client hostname, IP address, and other characteristics of client requests was done using the directives Order, Allow,Deny, and Satisfy.

In 2.4, such access control is done in the same way as other authorization checks, using the new module mod_authz_host. The old access control idioms should be replaced by the new authentication mechanisms, although for compatibility with old configurations, the new modulemod_access_compat is provided.

Here are some examples of old and new ways to do the same access control.

In this example, all requests are denied.

2.2 configuration:

Order deny,allow

Deny from all

2.4 configuration:

Require all denied

In this example, all requests are allowed.

2.2 configuration:

Order allow,deny

Allow from all

2.4 configuration:

Require all granted

In the following example, all hosts in the example.org domain are allowed access; all other hosts are denied access.

2.2 configuration:

Order Deny,Allow

Deny from all

Allow from example.org

2.4 configuration:

Require host example.org

Other configuration changes

Some other small adjustments may be necessary for particular configurations as discussed below.

·         MaxRequestsPerChild has been renamed toMaxConnectionsPerChild, describes more accurately what it does. The old name is still supported.

·         MaxClients has been renamed to MaxRequestWorkers, which describes more accurately what it does. For async MPMs, like event, the maximum number of clients is not equivalent than the number of worker threads. The old name is still supported.

·         The DefaultType directive no longer has any effect, other than to emit a warning if it's used with any value other thannone. You need to use other configuration settings to replace it in 2.4.

·         EnableSendfile now defaults to Off.

·         FileETag now defaults to "MTime Size" (without INode).

·         mod_log_config: ${cookie}C matches whole cookie names. Previously any substring would match.

·         mod_dav_fs: The format of the DavLockDB file has changed for systems with inodes. The old DavLockDB file must be deleted on upgrade.

·         KeepAlive only accepts values of On or Off. Previously, any value other than "Off" or "0" was treated as "On".

·         Directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath have been replaced with a single Mutex directive. You will need to evaluate any use of these removed directives in your 2.2 configuration to determine if they can just be deleted or will need to be replaced using Mutex.

·         mod_cache: CacheIgnoreURLSessionIdentifiers now does an exact match against the query string instead of a partial match. If your configuration was using partial strings, e.g. using sessionid to match/someapplication/image.gif;jsessionid=123456789, then you will need to change to the full string jsessionid.

·         mod_ldap: LDAPTrustedClientCert is now consistently a per-directory setting only. If you use this directive, review your configuration to make sure it is present in all the necessary directory contexts.

·         mod_filter: FilterProvider syntax has changed and now uses a boolean expression to determine if a filter is applied.

·         mod_include:

§  The #if expr element now uses the new expression parser. The old syntax can be restored with the new directive SSILegacyExprParser.

§  An SSI* config directive in directory scope no longer causes all other per-directory SSI* directives to be reset to their default values.

·         mod_charset_lite: The DebugLevel option has been removed in favour of per-module LogLevel configuration.

·         mod_ext_filter: The DebugLevel option has been removed in favour of per-module LogLevel configuration.

·         mod_ssl: CRL based revocation checking now needs to be explicitly configured through SSLCARevocationCheck.

·         mod_substitute: The maximum line length is now limited to 1MB.

·         mod_reqtimeout: If the module is loaded, it will now set some default timeouts.

Misc Changes

·         mod_autoindex: will now extract titles and display descriptions for .xhtml files, which were previously ignored.

·         mod_ssl: The default format of the *_DN variables has changed. The old format can still be used with the newLegacyDNStringFormat argument to SSLOptions. The SSLv2 protocol is no longer supported.SSLProxyCheckPeerCN and SSLProxyCheckPeerExpirenow default to On, causing proxy requests to HTTPS hosts with bad or outdated certificates to fail with a 502 status code (Bad gateway)

·         htpasswd now uses MD5 hash by default on all platforms.

·         The NameVirtualHost directive no longer has any effect, other than to emit a warning. Any address/port combination appearing in multiple virtual hosts is implicitly treated as a name-based virtual host.

·         mod_deflate will now skip compression if it knows that the size overhead added by the compression is larger than the data to be compressed.

·         Multi-language error documents from 2.2.x may not work unless they are adjusted to the new syntax ofmod_include's #if expr= element or the directiveSSILegacyExprParser is enabled for the directory containing the error documents.

·         The functionality provided by mod_authn_alias in previous versions (i.e., the AuthnProviderAlias directive) has been moved into mod_authn_core.

Third Party Modules

All modules must be recompiled for 2.4 before being loaded.

Many third-party modules designed for version 2.2 will otherwise work unchanged with the Apache HTTP Server version 2.4. Some will require changes; see the API update overview.

Common problems when upgrading

·         Startup errors:

§  Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration - load modulemod_unixd

§  Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration, orInvalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration- load module mod_access_compat, or update configuration to 2.4 authorization directives.

§  Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf - removeDefaultType and replace with other configuration settings.

·         Errors serving requests:

§  configuration error: couldn't check user: /path - load module mod_authn_core