[Linux] Announcing the Unbreakable Enterprise Kernel Release 4 Update 6 for Oracle Linux

原文はこちら。
https://blogs.oracle.com/linux/announcing-the-unbreakable-enterprise-kernel-release-4-update-6-for-oracle-linux

Oracle Linuxオペレーティングシステムはオープンなクラウドインフラストラクチャ向けに設計されており、従来のエンタープライズアプリケーションだけでなく、エンタープライズSaaSおよびPaaSワークロードにも優れたパフォーマンス、スケーラビリティ、信頼性を提供します。Oracle Linux Supportでは、受賞実績のあるOracleサポート・リソースやLinuxサポート・スペシャリスト、Kspliceを使用したゼロダウンタイムアップデート、Oracle Enterprise Managerなどの追加の管理ツール、およびライフタイム・サポートを低コストで提供します。また、他の多くの商用Linuxディストリビューションとは異なり、Oracle Linuxは簡単にダウンロードでき、完全に無料で使用、配布、および更新できます。

What's New?

Unbreakable Enterprise Kernel Release 4 Update 6では 4.1.12-112.14.1 を利用しており、さまざまなサブシステムにわたるいくつかの新機能、機能、バグ修正が含まれています。

Notable changes

  • Automatic NUMA balancing is disabled by default
    このアップデートでは、NUMA(Non-uniform Memory Access)自動バランシングの自動有効化が無効になっています。この変更により、NUMAの自動分散が有効になっている複数のNUMAノードを持つシステムで発生したいくつかの問題が解決されます。報告された事象・症状には、D状態で監察された(Oracle DBプロセスのような)高いiowait時間と多数のプロセスがあり、これらがプロセススタック内でwait_on_page_bit()関数を動作させない状況になっていたものがありました。
  • Deferred compaction of Transparent Hugepages is enabled
    Transparent Huge Pages(THP)の遅延コンパクション機能がメインラインカーネルからバックポートされ、デフォルトのデフラグ動作がmadviseに設定されています。これにより、メモリ断片化が原因でTHPからのhuge pageのアロケーションに時間がかかる場合に、THPによってアプリケーションの停止が発生する可能性があるという問題を解決します。

Crypto API

  • Addition of the ccp driver
    ccp ドライバによって、AMD Cryptographic Coprocessor(CCP)がサポートされます。AMD CCPにより、ハードウェア暗号化、ハッシュ生成やその他の関連する操作が利用可能になります。
  • Jitter entropy RNG added
    Jitter Entropy Random Number Generator (RNG) はLinuxカーネルとのCPU時間の差異によってCPUタイミングのエントロピーを収集する機能です。

DTrace

  • I/O provider for NFS
    このアップデートで、NFSへのstartdonereadおよびwriteリクエスト用のDTrace I/Oプロバイダ・プローブが追加されました。 
  • lockstat provider added
    DTraceがlockstatをサポートしたことにより、カーネルのロックイベントの動的な追跡が可能になりました。これにはどのロックが最もよく使われるのか、どのロックが最も競合を示しているのか、どのロックが最も保持されているのか、といったものが含まれます。
  • Packaging changes
    Unbreakable Enterprise Kernel Release 4 Update 6のリリースから、dtrace-modulesdtrace-modules-provider-headersおよびdtrace-modules-shared-headersパッケージは配布されなくなりました。これらのパッケージが提供する機能は、現在、ベースのkernel-uekおよび関連するヘッダーパッケージに含まれています。
上記の内容ならびにその他の新機能や変更点に関する詳細は、リリースノートをご覧ください。
Oracle® Linux Release Notes for Unbreakable Enterprise Kernel Release 4 Update 6
https://docs.oracle.com/cd/E37670_01/E92390/html/index.html 

Supported upgrade path

お客様は既存のOracle Linux 6およびOracle Linux 7サーバをUnbreakable Linux NetworkやOracle Linux Yum Serverを使ってアップグレードできます。
Unbreakable Linux Network
http://linux.oracle.com/
Oracle Linux Yum Server
http://yum.oracle.com/

Software Download

Oracle Linuxは無料でダウンロード、利用、配布できます。そして、全てのアップデートおよびエラータも無料でご利用いただけます。
Oracle Linux
http://www.oracle.com/linux
Free Updates and Errata for Oracle Linux
https://blogs.oracle.com/linux/free-updates-and-errata-for-oracle-linux
https://orablogs-jp.blogspot.jp/2012/03/free-updates-and-errata-for-oracle.html 
このしくみを利用して、どのシステムでサポートを契約するかを決定できますので、Oracle Linuxは開発、テスト、本番システムのための理想的な選択肢となることでしょう。
Oracle Linux Support
http://www.oracle.com/us/technologies/linux/support/overview/index.html
すべてのシステムを最新かつ安全に保ちながら、サポート対象範囲をシステムごとに個別に最適なものに決めてください。Oracle Linux Premier Supportをご利用のお客様は、Oracle Kspliceを使用したゼロ・ダウンタイムのカーネル・アップデートやOracle OpenStackのサポートもご利用いただけます。
Ksplice : Zero Downtime Updates for Oracle Linux
http://www.oracle.com/us/technologies/linux/ksplice-datasheet-487388.pdf
Oracle OpenStack Release 3
http://www.oracle.com/technetwork/server-storage/openstack/linux/documentation/datasheet-oracle-openstack-2296038.pdf

Compatibility

UEK R4 Update 6は以前のUEK R4 Updateと完全な互換性があります。UEK R4のカーネルABIは初期リリースに続く全てのリリースで変わりません。このリリースでは、カーネルABIがUEK R3に対して変更があるため、システム上の3rdパーティーカーネルモジュールを再コンパイルする必要があります。Before installing UEK R4をインストールする前に、お使いのアプリケーションベンダーにサポート状況を確認してください。

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

Product Training and Education

[Database] ODPI-C 2.1 is now available for all your Oracle Database Access Needs

原文はこちら。
https://blogs.oracle.com/opal/odpi-c-21-is-now-available-for-all-your-oracle-database-access-needs

ODPI-C

Anthony TuiningaがOracle Database Programming Interface for C (ODPI-C)のversion 2.1をGitHubにリリースしました。
Oracle Database Programming Interface for Drivers and Applications
https://github.com/oracle/odpi
ODPI-Cは、C言語やC++言語で記述されたアプリケーションがOracle Databaseに簡単にアクセスできるように作成された、C言語用オープンソースライブラリです。
主要な新機能:シャードされたデータベースへのアクセスをサポート
以下はAnthonyのコメントです。
このリリースでは、数ヶ月前にリリースされたversion 2.0 に対しいくつかの小さな機能強化を施しています。何よりも、Oracle Database 12.2の新機能であるシャードされたデータベースへのアクセスをサポートしました。また、SYSBACKUP、SYSDG、SYDKM、およびSYSRACのロールを使用した接続作成もサポートしました。サブスクリプション・メッセージを生成したトランザクションのIDの識別もサポートします。Windows環境では、誤ったアーキテクチャのOracle ClientがPATH環境変数にある場合に生成されるエラーメッセージが改善されました。デバッグ機能およびインフラストラクチャやテストスイートもかなり拡張・改善されています。ODPI-Cの改善ならびにODPI-Cを使用するcx_Oracle6.1とnode-oracledb 2.0の今後のリリースに向けて、多くのバグが修正されました。
cx_Oracle - Python Interface for Oracle Database
https://oracle.github.io/python-cx_Oracle/index.htmlnode-oracledb
https://www.npmjs.com/package/oracledb
詳細は、リリースノートをご覧ください。
ODPI-C Release notes
https://oracle.github.io/odpi/doc/releasenotes.html

ODPI-C References

[Docker, WLS] Run a WebLogic JMS Sample on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/run-a-weblogic-jms-sample-on-kubernetes

Overview

このエントリは、Kubernetesクラスタ内でWebLogic Server JMSアプリケーションのサンプルを構成し、実行するためのステップバイステップガイドです。まず、管理サーバとWebLogicクラスタを持つWebLogicドメインを作成する方法について説明した上で、WebLogic JMSリソースとデータソースを追加し、アプリケーションをデプロイして、最後にアプリケーションを実行します。
このアプリケーションは、WebLogic Serverのサンプルアプリケーションに含まれている 'Classic API - Using Distributed Destination' (分散送り先の使用)という名前のサンプルアプリケーションに基づいています。このアプリケーションは、従業員が到着時に自身の名前を送信し、スーパーバイザが従業員の到着時間を監視するというシナリオを実装したものです。
従業員は、チェックインメッセージの送信先(分散キューまたは分散トピック)を選択します。これらの宛先は、2つのアクティブな管理対象サーバが存在するクラスタ上で構成されています。これらの2つの宛先に対応する2つのmessage driven bean(MDB)がデプロイされ、チェックインメッセージを処理してデータベースに格納します。スーパーバイザーは、データベースに照会することですべてのチェックインメッセージをスキャンできます。

WebLogicの構成変更を自動化する方法には、主として、WLSTとREST APIがあります。KubernetesのWebLogicドメインでスクリプトやWLST、REST APIを実行するには、次の2つの方法があります。
  • KubernetesクラスタPod内でスクリプトを実行するこちらの方法を使う場合は、 'localhost'、NodePortサービス名、またはStatefulsetのヘッドレスサービス名と、Pod IP、Cluster IP、および内部ポートを使用します。このブログの手順では、 'localhost' を使用します。
  • Kubernetesクラスタ外でスクリプトを実行するこちらの方法を使う場合は、hostname/IPとNodePortを使用します。
このブログでは、REST APIを使用して管理サーバPod内のスクリプトを実行し、すべてのリソースをデプロイします。すべてのリソースはクラスタ全体を対象としています。クラスタが拡大または縮小する場合にうまく動作するため、Kubernetes上のWebLogic Serverの推奨アプローチです。

Creating the WebLogic Base Domain

GitHubのサンプルWebLogicドメインを使用してbaseドメインを作成します。
WebLogic Sample on Kubernetes with Shared Domain Home
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
このWebLogicサンプルアプリケーションには、​​Kubernetes上のWebLogicドメインでWebLogic Serverインスタンスとクラスタを構築して実行するためのDockerfile、スクリプト、yamlファイルがあります。サンプルドメインには、AdminServerという名前の管理サーバーと、managed-server-0からmanaged-server-3までの4つの管理対象サーバーを含むWebLogicクラスタが含まれています。今回4個の管理対象サーバを設定しますが、managed-server-0とmanaged-server-1の最初の2個だけ構成を開始します。
JMSサービスが他と異なる機能の一つとして、ステートフルであり、永続メッセージ、永続サブスクリプションなどといった、永続ストアにデータの大部分を保存する必要がある点があります。永続ストアは、データベースストアまたはファイルストアを使うことができます。このサンプルでは、​​外部ボリュームを使用してこのデータをファイルストアに格納する方法をご紹介します。
このWebLogicドメインでは、次の3つの永続ボリュームを構成します。
  • ドメインホームフォルダこのボリュームは、ドメイン内のすべてのWebLogic Serverインスタンス、つまり、管理サーバとWebLogicクラスタ内のすべての管理対象サーバーインスタンスが共有します。
  • ファイルストアこのボリュームは、WebLogicクラスタ内の管理対象サーバ・インスタンスが共有します。
  • MySQLデータベースこのボリュームの使用については、このブログの後半で説明します。
デフォルトでは、ドメインホームフォルダには、構成ファイル、ログファイル、診断ファイル、アプリケーションバイナリ、およびドメイン内の各WebLogic Serverインスタンスのデフォルトファイルストアファイルが含まれていることにご注意ください。カスタムファイルストアファイルもデフォルトでドメインホームフォルダに配置されていますが、このサンプルの設定をカスタマイズして、これらのファイルを個別の専用永続ボリュームに配置します。2つの永続ボリューム(ドメインホームとカスタムファイルストア)は、複数のWebLogic Serverインスタンスが共有します。それゆえ、Kubernetesクラスタが複数のマシンで実行されている場合、これらのボリュームは共用ストレージ内になければなりません。
README.mdファイルの手順を実行して、baseドメインを作成して実行し、すべてのWebLogic Serverインスタンス(管理サーバと2つの管理対象サーバ)が実行されるまで待ちます。管理サーバの実行、初期ドメインのプロビジョニングの完了後、管理対象サーバを順に開始するため、時間がかかることがあります。
$ kubectl get pod
NAME                           READY    STATUS    RESTARTS    AGE
admin-server-1238998015-kmbt9  1/1      Running   0           5m
managed-server-0               1/1      Running   0           3m
managed-server-1               1/1      Running   0           3m
ブログで使用するコマンドでは、$adminPodと$mysqlPodを実際のポッド名に置き換える必要があることに注意してください。

Deploying the JMS Resources with a File Store

ドメインが稼動中であれば、JMSリソースをデプロイできます。

まず、1つのファイルストア、1つのJMSサーバ、および1つのJMSモジュールの定義を含むJSONデータファイルを準備します。ファイルはPythonスクリプトが処理し、WebLogic ServerのREST APIを使用してリソースを1つずつ作成します。
file jms1.json:
{"resources": { 
  "filestore1": {
    "url": "fileStores",
    "data": {
      "name": "filestore1",
      "directory": "/u01/filestores/filestore1",
      "targets": [{
                 "identity":["clusters", "myCluster"]
                }]
    }
  },
  
  "jms1": {
    "url": "JMSServers",
    "data": {
      "messagesThresholdHigh": -1,
      "targets": [{
                   "identity":["clusters", "myCluster"]
                  }],
      "persistentStore": [
         "fileStores",
         "filestore1"
        ],
      "name": "jmsserver1"
    }
  },
  
  "module": {
    "url": "JMSSystemResources",
    "data": {
      "name": "module1",
      "targets":[{
                  "identity": [ "clusters", "myCluster" ]
                }]
    }
  },
  
  "sub1": {
    "url": "JMSSystemResources/module1/subDeployments",
    "data": {
      "name": "sub1",
      "targets":[{
                  "identity": [ "JMSServers", "jmsserver1" ]
                }]
    }
  }
}}
続いて、JMSモジュールファイルを準備します。これには接続ファクトリ、分散キュー、分散トピックが含まれます。
file module1-jms.xml:
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-jms http://xmlns.oracle.com/weblogic/weblogic-jms/1.1/weblogic-jms.xsd">
  <connection-factory name="cf1">
    <default-targeting-enabled>true</default-targeting-enabled>
    <jndi-name>cf1</jndi-name>
    <transaction-params>
      <xa-connection-factory-enabled>true</xa-connection-factory-enabled>
    </transaction-params>
    <load-balancing-params>
      <load-balancing-enabled>true</load-balancing-enabled>
      <server-affinity-enabled>false</server-affinity-enabled>
    </load-balancing-params>
  </connection-factory>
  <uniform-distributed-queue name="dq1">
    <sub-deployment-name>sub1</sub-deployment-name>
    <jndi-name>dq1</jndi-name>
  </uniform-distributed-queue>
  <uniform-distributed-topic name="dt1">
    <sub-deployment-name>sub1</sub-deployment-name>
    <jndi-name>dt1</jndi-name>
    <forwarding-policy>Partitioned</forwarding-policy>
  </uniform-distributed-topic>
</weblogic-jms>
3つめに、これらの2ファイルをコピーして管理サーバのPodに配置し、Pythonスクリプトを実行して管理サーバPod内でJMSリソースを作成します。
$ kubectl exec $adminPod -- mkdir /u01/wlsdomain/config/jms/
$ kubectl cp ./module1-jms.xml $adminPod:/u01/wlsdomain/config/jms/
$ kubectl cp ./jms1.json $adminPod:/u01/oracle/
$ kubectl exec $adminPod -- python /u01/oracle/run.py createRes /u01/oracle/jms1.json
ブラウザでhttp://<hostIP>:30007/consoleにアクセスしてWebLogic Server管理コンソールを開き、全てのJMSリソースが問題なく動作していることを確認します。

Deploying the Data Source

Setting Up and Running MySQL Server in Kubernetes

このサンプルはCheck-inメッセージをデータベースに格納します。それではMySQL Serverを構成しKubernetes上で動作するようにしましょう。

最初に、以下のものを準備します。
  • mysql.yml:暗号化されたユーザー名とパスワード資格証明を格納するシークレットが定義されている
  • 永続ボリュームクレーム(Permanent Volume Claim : PVC):外部ディレクトリにデータベース・データを格納するためのボリューム
  • MySQL Serverインストーラとサービス
base domainで、mysql.ymlで定義されたPVCが利用できるように、一つの永続ボリュームを予約して利用可能にしておきます。
file mysql.yml:
apiVersion: v1
kind: Secret
metadata:
  name: dbsecret
type: Opaque
data:
  username: bXlzcWw=
  password: bXlzcWw=
  rootpwd: MTIzNHF3ZXI=
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql-server 
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1beta1 
kind: Deployment 
metadata:
  name: mysql-server
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql-server 
    spec:
      containers:
      - name: mysql-server
        image: mysql:5.7
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3306
        env:
        - name:  MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: dbsecret
              key: rootpwd
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: dbsecret
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: dbsecret
              key: password
        - name: MYSQL_DATABASE
          value: "wlsdb"
        volumeMounts:
        - mountPath: /var/lib/mysql
          name: db-volume
      volumes:
      - name: db-volume
        persistentVolumeClaim:
          claimName: mysql-pv-claim
---
apiVersion: v1 
kind: Service
metadata:
  name: mysql-server
  labels:
    app: mysql-server 
spec:
  ports:
  - name: client
    port: 3306
    protocol: TCP
    targetPort: 3306
  clusterIP: None
  selector:
    app: mysql-server
続いて、MySQL ServerをKubernetesクラスタにデプロイします。
$ kubectl create -f mysql.yml

Creating the Sample Application Table

まず、サンプルのアプリケーション表のためのDDLファイルを準備します。
file sampleTable.ddl:
create table jms_signin (
          name varchar(255) not null,
          time varchar(255) not null,
          webServer varchar(255) not null,
          mdbServer varchar(255) not null);
続いて、MySQL Serverで表を作成します。
$ kubectl exec -it $mysqlPod -- mysql -h localhost -u mysql -pmysql wlsdb < sampleTable.ddl

Creating a Data Source for the WebLogic Server Domain

サンプルアプリケーションがMySQL Serverと通信できるよう、データソースを構成する必要があります。最初にFirst, prepare the ds1-jdbc.xml モジュールファイルを準備します。
file ds1-jdbc.xml:
<?xml version='1.0' encoding='UTF-8'?>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/jdbc-data-source http://xmlns.oracle.com/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
  <name>ds1</name>
  <datasource-type>GENERIC</datasource-type>
  <jdbc-driver-params>
    <url>jdbc:mysql://mysql-server:3306/wlsdb</url>
    <driver-name>com.mysql.jdbc.Driver</driver-name>
    <properties>
      <property>
        <name>user</name>
        <value>mysql</value>
      </property>
    </properties>
    <password-encrypted>mysql</password-encrypted>
    <use-xa-data-source-interface>true</use-xa-data-source-interface>
  </jdbc-driver-params>
  <jdbc-connection-pool-params>
    <capacity-increment>10</capacity-increment>
    <test-table-name>ACTIVE</test-table-name>
  </jdbc-connection-pool-params>
  <jdbc-data-source-params>
    <jndi-name>jndi/ds1</jndi-name>
    <algorithm-type>Load-Balancing</algorithm-type>
    <global-transactions-protocol>EmulateTwoPhaseCommit</global-transactions-protocol>
  </jdbc-data-source-params>
  <jdbc-xa-params>
    <xa-transaction-timeout>50</xa-transaction-timeout>
  </jdbc-xa-params>
</jdbc-data-source>
続いて、データソース・モジュールをWebLogic Serverドメインにデプロイします。
$ kubectl cp ./ds1-jdbc.xml  $adminPod:/u01/wlsdomain/config/jdbc/
$ kubectl exec $adminPod -- curl -v \
--user weblogic:weblogic1 \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d '{
"name": "ds1",
"descriptorFileName": "jdbc/ds1-jdbc.xml",
"targets":[{
"identity":["clusters", "myCluster"]
}]
}' -X POST http://localhost:8001/management/weblogic/latest/edit/JDBCSystemResources

Deploying the Servlet and MDB Applications

まず、2個のアプリケーション・アーカイブ(signin.war と signinmdb.jar)をダウンロードします。

以下のコマンドを入力してこれらの2個のアプリケーションをREST APIを使ってWebLogic Server管理サーバが動作しているPodにデプロイします。
# copy the two app files to admin pod
$ kubectl cp signin.war $adminPod:/u01/wlsdomain/signin.war
$ kubectl cp signinmdb.jar $adminPod:/u01/wlsdomain/signinmdb.jar

# deploy the two app via REST api
$ kubectl exec $adminPod -- curl -v \
--user weblogic:weblogic1 \
-H X-Requested-By:MyClient \
-H Content-Type:application/json \
-d "{
  name:       'webapp',
  sourcePath: '/u01/wlsdomain/signin.war',
  targets:    [ { identity: [ 'clusters', 'myCluster' ] } ]
}" \
-X POST http://localhost:8001/management/weblogic/latest/edit/appDeployments

$ kubectl exec $adminPod -- curl -v \
--user weblogic:weblogic1 \
-H X-Requested-By:MyClient \
-H Content-Type:application/json \
-d "{
  name:       'mdb',
  sourcePath: '/u01/wlsdomain/signinmdb.jar',
  targets:    [ { identity: [ 'clusters', 'myCluster' ] } ]
}" \
-X POST http://localhost:8001/management/weblogic/latest/edit/appDeployments
続いて、WebLogic Server管理コンソール(http://<hostIP>:30007/console)を開き、アプリケーションのデプロイに成功し、実行中であることを確認します。

Running the Sample

ブラウザで http://<hostIP>:30009/signIn/ にアクセスし、管理対象サーバ上にあるアプリケーションを起動します。数多くの異なるブラウザやマシンを使って複数のWebクライアントをシミュレートし、いくつかのユニークな従業員名を投稿します。その後、ブラウザで http://<hostIP>:30009/signIn/response.jsp にアクセスして結果を確認します。異なるレベルの2つの負荷分散がなされていることがわかるでしょう。
  • HTTPリクエストがクラスタ内の管理対象サーバ間で負荷分散されている。[Web Server Name]という列のエントリを見ると、従業員のチェックインごとに、このカラムで、対応するHTTPリクエストを処理しているサーブレットインスタンスを含むWebLogic Serverインスタンスの名前を確認できる。
  • 分散送り先に送信されたJMSメッセージは、クラスタ内のMDBインスタンス間で負荷分散されている。[MDB Server Name]という列のエントリを見ると、メッセージを処理しているMDBインスタンスを含むWebLogic Serverインスタンスを確認できる。

Restarting All Pods

Restart the MySQL、WebLogic Server管理サーバと管理対象サーバのPodをそれぞれ再起動します。ここでは外部ボリュームにあるデータが確かにPodのライフサイクルとは関係なく保存されていることを説明します。

まず、正常にMySQL Podを停止します。
$ kubectl exec -it $mysqlpod /etc/init.d/mysql stop
Podが停止したら、Kubernetesコントロール・パネルが自動的に再起動させるでしょう。

続いて、README.mdの"Restart Pods"の章に移り、全てのWebLogic ServerのPodを再起動します。
$ kubectl get pod
NAME                            READY   STATUS   RESTARTS   AGE
admin-server-1238998015-kmbt9   1/1     Running  1          7d
managed-server-0                1/1     Running  1          7d
managed-server-1                1/1     Running  1          7d
mysql-server-3736789149-n2s2l   1/1     Running  1          3h
各Podの再起動のカウントがインクリメントされ、0から1に変わったことがわかるでしょう。

全てのPodが再起動したら、WebLogic Server管理コンソールにアクセスしてサーバがRUNNING状態になっていることを確認します。サーバが再起動すると、全てのメッセージがリカバリされます。全てのデータは外部データボリュームに格納されており、そのためPodの再起動後リカバリできるため再起動前と同じ結果を確認できます。

Cleanup

以下のコマンドを入力して、MySQL Serverインスタンスが利用していたリソースのクリーンアップを実施します。
$ kubectl delete -f mysql.yml
続いて、README.mdの "Cleanup" の章に従い、base domainを削除し、このサンプルで利用したその他全てのリソースを削除します。

Summary and Futures

このエントリでは、KubernetesをWebLogic Server JMSクラスタをホストするための柔軟でスケーラブルな環境として使用する方法をご紹介しました。基本的なKubernetesの機能を利用して、WebLogicサーバーのライフサイクルを管理し、ファイルベースのメッセージ永続性を使用し、Java EEアプリケーション間のクラスター内JMS通信を実証しました。また、ポッドのライフサイクルを超えてデータを維持するため、Kubernetes Pod外の共有データボリュームにファイルを外出しすることで、FileベースのJMS永続化がうまく機能することも実証しました。
今後のエントリで、WebLogicの将来的に完全に動作保証されたWebLogicのKubernetes ‘operator based’のKubernetes環境を使用してWebLogic JMSクラスタをホストする方法を紹介することを検討しています。さらに、外部JMSクライアントを使用して、Kubernetesクラスタ内で動作するWebLogic JMSサービスと通信する方法、永続ストアとしてファイルの代わりにデータベースを使用する方法、WebLogic JMS自動サービス移行を使用してJMSインスタンスをシャットダウンされたPodから実行中のPodに自動的に移行する方法についても説明する予定です。

[Java] OSSユーザーのための勉強会 #21 Java EE

先日OSSユーザーのための勉強会という枠でJava EEならびにJava EE 8についてお話する時間を頂きました。主催のSCSK様をはじめとする関係者のみなさま、どうもありがとうございました。
OSSユーザーのための勉強会 <OSS X Users Meeting> #21 Java EE
http://eventregist.com/e/ossx2017-12
当日は当方がJava EE の概要と特徴(ほとんどはJava EE 8の概要や新機能)、伊藤さん( @itakash )がJava EE の最新動向と今後の方向性についてお話しました。
当方ならびに伊藤さんのスライドは主催者であるSCSK様のページから近日公開される予定になっていますが、当方分はSlideShareにUpしましたので、ご興味あればどうぞ。


[Docker, WLS] Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/use-prometheus-and-grafana-to-monitor-weblogic-server-on-kubernetes

Kubernetes上でのWeblogic Serverの動作保証検証の一環として、WebLogicチームは、Kubernetes環境でWebLogic Serverクラスタのオーケストレーションのデモサンプルを作成しました。
WebLogic on Kubernetes Sample
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s
このサンプルには、WebLogic Monitoring Exporterが含まれており、特定のWebLogic Serverインスタンスの実行時メトリックを取得し、PrometheusおよびGrafanaツールに供給することができます。
Exporting Metrics from WebLogic Server
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
https://orablogs-jp.blogspot.jp/2017/11/exporting-metrics-from-weblogic-server.html
Prometheus - Monitoring system & time series database
https://prometheus.io/
Grafana - The open platform for analytics and monitoring
https://grafana.com/
Weblogic Monitoring Exporterは監視したいWebLogic Serverインスタンスにデプロイ可能なWebアプリケーションです。Weblogic Monitoring ExporterはWebLogic Server 12.2.1.xのRESTful管理インターフェースを使ってランタイム状態やメトリックにアクセスします。
Oracle® Fusion Middleware RESTful管理サービスによるOracle WebLogic Serverの管理 12c (12.2.1.2.0)
WLS RESTful管理インタフェースについて
https://docs.oracle.com/cd/E84527_01/wls/WLRUR/overview.htm#GUID-B193E8EF-1912-48D1-8FB9-99C5ADACCC3B
Oracle® Fusion Middleware Administering Oracle WebLogic Server with RESTful Management Services 12c (12.2.1)
About the WLS RESTful Management Interface
https://docs.oracle.com/middleware/1221/wls/WLRUR/overview.htm#WLRUR111
WebLogic Monitoring Exporter構成や利用方法に関する詳細は、以下のエントリをご覧ください。
Exporting Metrics from WebLogic Server
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
https://orablogs-jp.blogspot.jp/2017/11/exporting-metrics-from-weblogic-server.html
このエントリでは、PrometheusやGrafanaを構成し、Kubernetesクラスタで動作しているWebLogic Serverインスタンスの監視方法をご紹介します。

Monitoring Using Prometheus

WebLogic Monitoring Exporterを使用して、WebLogic Serverのメトリックを取得し、Prometheusにフィードします。以前のブログエントリでは、Kuberbetesクラスタで動作している管理対象サーバにWebLogic Monitoring Exporterをデプロイして、KubernetesでWebLogic Serverインスタンスを起動および実行する方法について説明しました。
WebLogic on Kubernetes, Try It!
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes%2c-try-it
https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html
WebLogic Monitoring Exporterがデプロイされ実行されていることを確認するには、次のリンクをクリックします。
http://[hostname]:30011/wls-exporter/metrics
メトリックデータにアクセスするために必要なWebLogicユーザー資格情報の入力を求められます(例えばweblogic/weblogic1)。メトリックページでは、WebLogic Monitoring Exporter用に構成されたメトリックを表示します。

To create a Prometheus instance in KubernetesにPrometheusインスタンスを作成するには、Prometheus構成ファイル(prometheus-kubernetes.yml)を作成する必要があります。サンプルファイルを用意しましたので、これを環境にあわせて変更してください。
docker-images/OracleWebLogic/samples/wls-K8s/prometheus/
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s/prometheus
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v1.7.1
        ports:
        - containerPort: 9090
        args:
        - -config.file=/etc/prometheus/prometheus.yml
        volumeMounts:
        - mountPath: /etc/prometheus/
          name: config-volume
#        - mountPath: /prometheus
#          name: prometheus-data
      restartPolicy: Always
      volumes:
      - name: config-volume
        configMap:
          name: prometheus-configuration
#      - name: prometheus-data
#        persistentVolumeClaim:
#          claimName: prometheus-storage
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-configuration
data:
  prometheus.yml: |-
    global:
      scrape_interval:     5s
      external_labels:
        monitor: 'my-monitor'
    scrape_configs:
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: pod_name
      - regex: '(controller_revision_hash|job)'
        action: labeldrop
      - source_labels: [name]
        regex: '.*/(.*)$'
        replacement: $1
        target_label: webapp
      basic_auth:
       username: weblogic
       password: weblogic1

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus-storage
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
status: {}
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  type: NodePort
  ports:
  - port: 9090
    targetPort: 9090
    nodePort: 32000
  selector:
    app: prometheus
上記Prometheus構成ファイルの例では以下のように指定しています。
  • ユーザー資格証明はweblogic/weblogic1
  • WebLogic Serverのメトリックの更新間隔は5秒
  • Prometheusダッシュボードへアクセスするための外部ポートは32000/tcp
これらの値は皆様の特定の環境や構成を反映するために、必要に応じて変更できます。
Start Prometheusを起動して、管理対象サーバインスタンスを監視します。
$ kubectl create -f prometheus-kubernetes.yml
Prometheusがすべての管理対象サーバを監視していることを確認するために、以下のURLをブラウザで確認します。
http://[hostname]:32000
カーソルのプルダウンでInsertメトリックを調べます。WebLogic Monitoring Exporter Webアプリケーションの現在の設定に基づいてメトリック名がリスト表示されます。

WebLogic Monitoring Exporterを正しく構成していることを確認するためには、以下のURLにブラウザで接続します。
http//:[hostname]:30011/wls-exporter
現在の構成が下図のように表示されるはずです。

以下は対応するWebLogic Monitoring Exporterの構成ファイルです。
metricsNameSnakeCase: true
queries:
- applicationRuntimes:
    key: name
    keyName: app
    componentRuntimes:
      type: WebAppComponentRuntime
      prefix: webapp_config_
      key: name
      values: [deploymentState, contextRoot, sourceInfo, openSessionsHighCount, openSessionsCurrentCount, sessionsOpenedTotalCount, sessionCookieMaxAgeSecs, sessionInvalidationIntervalSecs, sessionTimeoutSecs, singleThreadedServletPoolSize, sessionIDLength, servletReloadCheckSecs, jSPPageCheckSecs]
      servlets:
        prefix: weblogic_servlet_
        key: servletName
        values: [invocationTotalCount, reloadTotal, executionTimeAverage, poolMaxCapacity, executionTimeTotal, reloadTotalCount, executionTimeHigh, executionTimeLow]
- JVMRuntime:
    key: name
    values: [heapFreeCurrent, heapFreePercent, heapSizeCurrent, heapSizeMax, uptime, processCpuLoad]
上記構成ファイルはWebLogic Monitoring ExporterのWARファイルに埋め込まれていました。メトリックデータの変更や追加をする場合は、単純にランディングページ(http//:[hostname]:30011/wls-exporter)に接続して[Append or Replace]ボタンをクリックし、構成ファイルをyml形式でロードします。以下はその例です(workmanager.yml)。
metricsNameSnakeCase: true
queries:
- applicationRuntimes:
    key: name
    workManagerRuntimes:
      prefix: workmanager_
      key: applicationName
      values: [pendingRequests, completedRequests, stuckThreadCount]
prometheusが定義するクエリを構築することで、WebLogicドメインで動作しているサーバやアプリケーション、リソースの監視・診断に必要な任意のデータを取り出すことができます。
QUERYING PROMETHEUS
https://prometheus.io/docs/querying/basics/
例えば、以下のクエリを入力すると、PrometheusはWebLogicクラスタ内で実行中のすべての管理対象サーバから現在のデータを返します。
weblogic_servlet_execution_time_average > 1

Prometheusはデータに基づいてグラフも生成します。例えば、Graphタブをクリックすると、Prometheusは平均実行時間がしきい値である1秒を超過するServletの数を示すグラフを生成します。

Monitoring Using Grafana

複数のグラフを持つ可視性の高いダッシュボードを使用するには、Grafanaを使用します。
以下は設定ファイル(grafana-kubernetes.yml)の例で、これを使いKubernetes環境でGrafanaを起動することができます。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grafana
  labels:
    app: grafana
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:4.4.3
        ports:
        - containerPort: 3000
        env:
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: pass
#        volumeMounts:
#        - mountPath: /var/lib/grafana
#          name: grafana-data
      restartPolicy: Always
      volumes:
#      - name: grafana-data
#        persistentVolumeClaim:
#          claimName: grafana-data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  name: grafana-data
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: grafana
  name: grafana
spec:
  type: NodePort
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 31000
  selector:
    app: grafana
Grafanaを起動して管理対象サーバを監視するには、以下のkubectlコマンドを実行します。
$ kubectl create -f grafana-kubernetes.yml
http://[hostname]:31000 でGrafanaに接続できるので、ホームページにログイン(ユーザー名はadmin、パスワードはpass)すると、Grafanaのホームページが表示されます。

GrafanaをPrometheusに接続するには、[Add Data Source] を選択し、以下の値を入力します。
Name: Prometheus
Type: Prometheus
Url: http://prometheus:9090
Access: Proxy

[Dashboards] タブを選択し、[Import]をクリックします。

これで、WebLogic Serverを監視するダッシュボードの作成準備ができたので、以下の操作を完了させます。
  1. ホームページ左上部のGrafanaのアイコンをクリックし、Dashboards>Newを選択
  2. Graphを選択し、空白スペースにDragすると、空のグラフパネルができる。
  3. パネル上をクリックし、editを選択すると、編集可能なパネルが開き、メトリックグラフの表示方法をカスタマイズできる。
  4. GraphパネルでGeneralタブを選択し、タイトルに「WebLogic Servlet Execution Average Time(WebLogicサーブレット実行平均時間)」と入力。
  5. Metricsタブを選択し、Panel Data SourceのプルダウンメニューでPrometheusを選択。
空のMetric参照フィールドをクリックすると、Prometheusの場合と同様に、WebLogic Monitoring Exporterで設定されたすべてのメトリックを引き込みます。 Prometheusの例で指定したweblogic_servlet_execution_time_average> 1というクエリを入力すると、クラスタ内のすべての管理対象サーバ上で平均実行時間が1秒を超えるすべての利用可能なServletのデータが生成されてグラフとして表示されます。 各色は特定のPodとServletの組み合わせを表します。

特定のPodのデータを表示するには、対応する凡例をクリックします。これにより、他のPodのデータはグラフからすべて削除され、その凡例は強調表示されなくなります。データを追加するには、シフトキーを押して任意の凡例をクリックします。リセットするには、もう一度同じ凡例をクリックすると、他のすべてのグラフがグラフに再表示されます。
凡例をカスタマイズするには、Legend Formatフィールドで目的の値をクリックします。 例えば以下の値をクリックした場合、Grafanaはカスタマイズされた凡例を表示し始めます。グラフをクリックすると、選択した時間のすべての値が表示されます。
{{pod_name}} :appName={{webapp}} : servletName={{servletName}}

Graph→Legendタブを選択すると、凡例をさらにカスタマイズできます。例えば、凡例の配置を移動したり、最小値、最大値、平均値などを表示することができます。
Graph→Axesタブを選択すると、単位を対応するメトリックデータに切り替えることができます。この例では、時間(ミリ秒)です。
Grafanaはアラートツールも提供しています。例えば、指定した条件にアラートを設定できます。下の例では、Servletの平均実行時間が100ミリ秒を超えると、Grafanaはアラートを送出し、管理者に電子メールを送信します。

最後に、Prometheusのデータ収集間隔と同じリフレッシュ間隔である5秒ごとにグラフをリフレッシュする必要があります。また、データを監視する時間範囲をカスタマイズすることもできます。
そのためには、作成したダッシュボードの右上隅をクリックする必要があります。デフォルトでは、現在の時刻までの過去6時間のメトリックを表示するように設定されているので、必要な変更を行います。例えば、5秒ごとに更新してApplyをクリックします。

完了したら、画面の左上部にある[Save]をクリックして、ダッシュボードの名前を指定するだけです。

Summary

WebLogic Serverには豊富な一連のメトリックが用意されており、このメトリックはWebLogic Server Administration ConsoleやMonitoring Dashboardなどのよく知られたツールを使用して監視できます。これらのツールを使って、KubernetesにデプロイされているWebLogic Serverで実行されているWebLogic Serverインスタンス、アプリケーション、およびリソースを監視できます。このコンテナ・エコシステムにおいて、Kubernetes上で実行されているWebLogic Serverインスタンスのクラスタからメトリックをエクスポートおよび監視する別の方法をPrometheusやGrafanaのようなツールが提供します。また、こうしたツールを使うと、ドメインを再起動せずに、監視データを簡単に収集、アクセス、表示、カスタマイズすることができますし、さらにアラートを作成し、関係者に通知を簡単に送信することができます。是非使い始めてください。きっと気に入っていただけることでしょう!

[Docker, WLS] Announcing the New WebLogic Monitoring Exporter

原文はこちら。
https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-monitoring-exporter-v2

まもなくKubernetesでのWebLogic Serverの動作保証を発表する予定です。 Docker/Kubernetes環境でWebLogicドメインを実行する際にユーザーに最高のエクスペリエンスを提供するため、WebLogic Monitoring Exporterを開発しました。この新しいツールでは、Prometheusなどの監視ツールが読み込み収集し、Grafanaに表示するWebLogic Serverのメトリクスを公開します。 また、WebLogic Monitoring Exporterツールは以下のURLからオープンソースとしてご利用いただけますので、コミュニティがこのプロジェクトに貢献し、機能強化に参加いただけます。
weblogic-monitoring-exporter
https://github.com/oracle/weblogic-monitoring-exporter

実行すると、サーバ、クラスタ、アプリケーションや、WebLogicドメイン上で動作しているその他のリソースに関する詳細なパフォーマンスや診断データを提供する豊富な一連のメトリックとランタイムのステート情報をWebLogic Serverが生成します。WebLogic Monitoring Exporterを使って、Kubernetes環境の管理者は、PrometheusやGrafanaといった、Kubernetes環境を監視するためによく利用されるツールを使用して、このデータを簡単に監視できます。
WebLogic Monitoring Exporterの設計と実装の詳細については以下のドキュメントをご覧ください。
Exporting Metrics from WebLogic Server
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
https://orablogs-jp.blogspot.jp/2017/11/exporting-metrics-from-weblogic-server.html
PrometheusやGrafanaを用いたKubernetes上のWebLogic Serverの監視については以下のURLをご覧ください。
Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes
https://blogs.oracle.com/weblogicserver/use-prometheus-and-grafana-to-monitor-weblogic-server-on-kubernetes
KubernetesでのWebLogic Serverの動作保証に関する詳細はしばしお待ちください。我々の目的は、WebLogic ServerをKubernetesベースのOracle Container Engineで実行し、WebLogic ServerアプリケーションをKubernetesベースのContainer Native Application Development Platformで開発されたアプリケーションとの統合を可能にすることを目的としています。
Announcing Oracle Container Engine and Oracle Container Registry Service
https://blogs.oracle.com/developers/announcing-oracle-container-engine-and-oracle-container-registry-service
https://orablogs-jp.blogspot.jp/2017/11/announcing-oracle-container-engine-and.html
Meet the New Application Development Stack - Managed Kubernetes, Serverless, Registry, CI/CD, Java
https://blogs.oracle.com/developers/meet-the-new-application-development-stack-kubernetes-serverless-registry-cicd-java

[Linux] Announcing Oracle Linux 7 for ARM

原文はこちら。
https://blogs.oracle.com/linux/announcing-oracle-linux-7-for-arm

Oracle Linuxはオープンなクラウドインフラストラクチャ向けに設計されています。従来のエンタープライズアプリケーションだけでなく、エンタープライズSaaSおよびPaaSワークロードに対しても優れたパフォーマンス、拡張性、信頼性を提供します。
Oracle Linux 7 Update 3 for ARMは、ARMプラットフォームで動作するOracle Linuxの最初の一般公開版です。このリリースは、対応するx86アーキテクチャ用のOracle Linuxディストリビューションと同じソースパッケージに加えて、ARMプラットフォーム上で実行するために必要なパッチおよび修正が組み込まれています。
Oracle Linux 7 Update 3 for ARMはx86プラットフォーム用のOracle Linux 7 Update 3に基づいていますが、2つのプラットフォームのリリースの違いは、パッケージングとカーネルのバージョンです。64ビットARMアーキテクチャ用に構築されたパッケージは、aarch64アーキテクチャコードを使用するため、x86プラットフォームで使用可能なパッケージの中には、このリリースでは利用できないものがあります。このプラットフォーム用に正常にビルドするために、パッチをパッケージに適用したり、一部のパッケージでは新しいバージョンに上げられたりしている可能性があります。

Support

Oracle Linux 7 update 3はARMプラットフォームで動作する最初の一般公開版で、開発者やパートナーの利便のための開発者リリース(developer release)としてご利用いただけます。OracleはOracle Linux 7 Update 3 (ARM)に対するサポートを提供しません。

Availability

Oracle Linux 7 Update 3 for ARMは、開発者プレビュー版としてリリースされます。この目的のため、次の2つの形式でリリースをご利用になれます。
  • Raspberry Pi™3 Model Bシングルボードコンピュータで使用するためにSDカードにインストールできるディスクイメージ。このイメージには、Raspberry Pi 3を直接Oracle Linux 7でブートするために必要なファームウェアが含まれています。このイメージは、代替ARMハードウェアにアクセスできない開発者が利用できます。
  • 汎用64ビットARMv8ハードウェア上への標準インストールに使用できるISOイメージ。このISOイメージはARMハードウェア上でテストされており、Cavium ThunderX®およびX-Gene 3 ARMプロセッサで利用するために設計されています。
Oracle Linux 7 Update 3 for ARMは、Oracle Technology Networkからダウンロードできます。ダウンロード、配布、および使用は自由です。
Oracle Linux for ARM Downloads
http://www.oracle.com/technetwork/server-storage/linux/downloads/oracle-linux-arm-4072846.html

Installation

Raspberry Piやその他のARMベースのハードウェアにOracle Linux 7をインストールする手順の詳細は、Oracle Linux 7 Update 3 for ARMのリリースノートをご覧ください。

Oracle Linux Resources

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

Product Training and Education

"Raspberry Pi" はthe Raspberry Pi Foundationのトレードマークです。