[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のトレードマークです。

[Cloud, Virtualization] Bring your Oracle VM workloads to Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/bring-your-oracle-vm-workloads-to-oracle-cloud-infrastructure

このエントリはOmair Gillani(Sr. Principal Product Manager, Oracle Cloud Infrastructure Team)によるものです。

Oracle Cloud Infrastructure上でオラクルの最新のサーバー仮想化製品であるOracle VM 3.4の提供を発表できうれしく思っています。これにより、既存のOracle VMベースのワークロードを「そのまま」持ち運び、Oracle Cloudで実行できるようになります。持ち込み対象のワークロードには、業界をリードするOracle Database製品が含まれます。拡張性が高く高性能のOracle VMがクラウドに展開されたことで、Oracleの革新的なオンデマンドのベア・メタル・コンピューティング・インスタンスを利用できるようになりました。Oracle VM Requirements and Installation Guideで簡単に始めることができます。
Installing and Configuring Oracle VM on Oracle Cloud Infrastructure
https://docs.us-phoenix-1.oraclecloud.com/Content/Resources/Assets/ovm_on_oci.pdf
クラウドに新しいインフラストラクチャを構築しているOracleのお客様は、Oracle Linux、Microsoft Windows、Ubuntu、およびCentOSの事前構築済イメージで提供されるネイティブな仮想化の恩恵を受けることができます。また、既存の仮想化ワークロードをクラウドに移行し、Oracle Cloud Infrastructure上でOracle VMに移行することもできます。
Oracle VM用に事前にパッケージ化されたOracle Cloud Infrastructureのイメージには、以下のものが含まれます。
  1. Oracle VM Server
    x86ベアメタル・ハードウェア上で仮想マシンを実行する軽量で安全な仮想化プラットフォーム
  2. Oracle VM Manager
    Oracle VM環境を構成および管理できるアプリケーション
Oracle VMは、次のようなワークロードに対して認定された仮想化ソリューションを提供します。
  • Oracle Database、Middleware、Applicationだけでなく、3rdパーティ製の多くのアプリケーションといったエンタープライズ・アプリケーションの迅速な展開を実現します
  • 最新のOracle Linux、Microsoft Windows、Oracle Solaris、その他多くのLinuxディストリビューションをサポートします。また、Oracle VM上で多くのレガシー・オペレーティング・システムを実行することもできます。
  • 既存のOracle VMオンプレミスのナレッジやプラクティス、ツール、およびサポートをOracle Cloud Infrastructureでのデプロイメントに適用できます。
  • オンプレミスからOracle Cloud Infrastructureにワークロードを簡単に移行できます。
ハイパーバイザ用のベアメタル・インスタンス1個と、Oracle VM Managerインスタンス用の小さなVMを使用して、基本的なOracle VM環境をセットアップできます。 ハイパーバイザーの場合、Dense I/Oコンピューティング・インスタンスの高速かつ低遅延のローカルNVMeストレージや、耐久性の高いOracle Cloud Infrastructure Block Storageを使用できます。

Oracle VMイメージは、Phoenix、Ashburn、Frankfurtを含むすべてのOracle Cloud Infrastructureリージョンで使用できます。

[Java, WLS] Exporting Metrics from WebLogic Server

原文はこちら。
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server

WebLogic Serverは実行時にたくさんの一連のメトリックとランタイムのステート情報を生成します。呼び出し件数、セッション・アクティビティ、ワークマネージャー・スレッドなど、数千ものメトリックを使用してパフォーマンス・データを取得できます。これらのメトリックは、アクティビティの追跡、問題の診断、十分なリソースが利用可能であることを保証する上で非常に役立ちます。メトリックはJMXとWebサービスの両方で公開され、Enterprise ManagerやWebLogic Server Administration ConsoleなどのOracle管理ツールやサードパーティのクライアントでサポートされています。
そんなサードパーティ・クライアントの1つにPrometheusがあります。
Prometheus - Monitoring system & time series database
https://prometheus.io/
Prometheusは、クラウド環境で時系列データの収集、保存、クエリのフレームワークとしてよく使われるオープンソースの監視ツールキットです。さまざまなサービスからの情報を収集し、その情報をPrometheusサーバーに供給するための数多くのExporterが作られています。
Exporters and Integrations
https://prometheus.io/docs/instrumenting/exporters/
データがPrometheusに入ると、Prometheus自体、またはPrometheusのデータを処理できるGrafanaなどのツールを使用して取得できます。
Grafana - The open platform for analytics and monitoring
https://grafana.com/
Oracleのお客様は、汎用的なPrometheus JMX Exporterを使用してWebLogic Serverインスタンスから情報を取得していますが、このソリューションは、より大きなサイトでのユーザビリティの問題とスケーラビリティがネックになっています。
prometheus/jmx_exporter
https://github.com/prometheus/jmx_exporter
MBeanツリーの次の部分を考えてみましょう。

このツリーでは、ServerRuntimeはMBeanツリーの最上位で、複数のApplicationRuntime MBeanを持ちます。各々のApplicationRuntime MBeanは複数のComponentRuntime MBeanを有しています。 それらの中には、複数のServlet MBeanを持つWebAppComponentRuntime型のものがあります。次のようにJMX Exporterを構成することができます。
jmxUrl: service:jmx:t3://@HOST@:@PORT@/jndi/weblogic.management.mbeanservers.runtime
username: system
password: gumby1234
lowercaseOutputName: false
lowercaseOutputLabelNames: false
whitelistObjectNames:
  - "com.bea:ServerRuntime=*,Type=ApplicationRuntime,*"
  - "com.bea:Type=WebAppComponentRuntime,*"
  - "com.bea:Type=ServletRuntime,*"

rules:
  - pattern: "^com.bea<ServerRuntime=.+, Name=(.+),  ApplicationRuntime=(.+), Type=ServletRuntime,  WebAppComponentRuntime=(.+)><>(.+): (.+)"
    attrNameSnakeCase: true
    name: weblogic_servlet_$4
    value: $5
    labels:
      name: $3
      app: $2
      servletName: $1

  - pattern: "^com.bea<ServerRuntime=(.+), Name=(.+),  ApplicationRuntime=(.+), Type=WebAppComponentRuntime><>(.+):  (.+)$"
    attrNameSnakeCase: true
    name: webapp_config_$4
    value: $5
    labels:
      app: $3
      name: $2
これにより適切なMBeansが選択され、Exporterが以下のようなメトリックを生成することができます。
webapp_config_open_sessions_current_count{app="receivables",name="accounting"} 3
webapp_config_open_sessions_current_count{app="receivables",name="inventory"} 7
weblogic_servlet_invocations_total_count{app="receivables",name="accounting",servletName="Balance"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="accounting",servletName="Login"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="inventory",servletName="Count"} 0
weblogic_servlet_invocations_total_count{app="receivables",name="inventory",servletName="Reorder"} 0
しかしこのアプローチには課題があります。JMX Exporterは、Javaエージェントとして実行する必要があるため、設定が難しい場合があります。さらに、JMXはRMI上に構築されており、JMX over RMI/IIOPはJava SE 9以降でJREから削除されているため、Exporterはプラットフォーム固有のRMI実装パッケージにする必要があります。
JMX Exporterもややプロセッサに負荷を掛けます。ツリー内の各Beanを取得するためにJMXを別々に起動する必要があるため、サーバーで処理を行う必要があります。Exporterの設定は、MBean名と正規表現に依存しているため、難しい場合があります。論理的には、特定のMBeanの属性のサブセットを選択することは可能ですが、実際には正規表現にさらに複雑さが加わり、実現困難になるでしょう。その結果、すべての情報を収集してデータ伝送およびストレージのコストを負担しつつ、データを最終的に表示するときにのみフィルタリングすることが一般的です。

The WebLogic Monitoring Exporter

JMXとともに、Oracle WebLogic Server 12.2.1以降で、ランタイムの状態およびメトリックにアクセスするための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
このインターフェースには強力なバルクアクセス機能が含まれているため、クライアントは、必要な情報を正確に記述し、当該情報のみを含む単一の応答を取得するクエリをPOSTすることができます。
Oracleは、このインタフェースを利用するWebLogic Monitoring Exporterを作成しました。
oracle/weblogic-monitoring-exporter
https://github.com/oracle/weblogic-monitoring-exporter
このExporterは、監視対象のWebLogic ServerインスタンスにデプロイされるWebアプリケーションとして実装されています。その設定は、ServerRuntime MBeanの下から始まるMBeanツリーに明示的に従います。
先ほどの例と同じ結果を得るには、以下のように呼び出します。
metricsNameSnakeCase: true 
queries: 
  - applicationRuntimes:
     key: name
     keyName: app
     componentRuntimes:
       type: WebAppComponentRuntime
       prefix: webapp_config_
       key: name
       values: [openSessionsCurrentCount, openSessionsHighCount]
       servlets:
         prefix: weblogic_servlet_
         key: servletName
このExporterで、所望のメトリックを単一のHTTPクエリを使って取得できます。複数回のJMXクエリや、特殊な設定は不要で、MBeanのために生成されたメトリックを簡単に選択することができます。
Exporterは常にデプロイ先のサーバに接続しているため、URLを指定する必要がないことにご注意ください。ユーザー名やパスワードを指定するのではなく、クライアントがメトリックを読み取ろうとする場合にメトリックを指定する必要があります。

Managing the Application

ExporterはWebアプリケーションなので、ランディングページがあります。

ランディングページにはメトリックのリンクが含まれているだけでなく、常に現在の構成も表示しています。最初にアプリケーションがロードされた時は、WARファイルに埋め込まれている構成を使います。しかしながら、ランディングページには新たなyamlファイルを選択することで構成を変更できるようなフォームがあります。
新たなファイルからのクエリのみを使用し、送信前にAppendボタンを選択してクエリを組み合わせることができます。
例えば、いくつかのJVMメトリックを追加してみましょう。

次回クライアントがメトリックのURLにアクセスすると、新しいメトリックをレポートします。上記の新たな要素は以下のようなメトリックを生成します。
jvm_heap_free_current{name="myserver"} 285027752
jvm_heap_free_percent{name="myserver"} 71
jvm_heap_size_current{name="myserver"} 422051840

Metrics in a WebLogic Server Cluster

もちろん、WebLogic Serverクラスタでは、単一のサーバインスタンスで収集したメトリックを変更してもほとんど意味がありません。すべてのクラスタメンバーが同じアプリケーションをホストしているため、同じメトリックを報告させるようにします。このためには、いずれかのサーバに加えられた変更に対してすべてのサーバーが応答するように設定する必要があります。Exporterでは、別のconfig_coordinatorプロセスを使用して変更を追跡することでこの課題に対応します。
これを使用するには、クエリ同期を記述する新しい最上位の要素を初期構成に追加する必要があります。
query_sync:
  url: http://coordinator:8099
  refreshInterval: 10  
ここでは、個別のDockerコンテナで実行されるconfig_coordinatorプロセスのURLを指定します。Exporterがはじめて起動した際、構成にこの要素が含まれている場合は、coordinatorに連絡して、新しい構成があるかどうかを確認します。 その後、ランディングページまたはメトリックページのいずれかがクエリされるたびに実行されます。 オプションのrefreshInterval要素は、Exporterが構成の更新を探す頻度を制限します。refreshIntervalがあれば、サーバーを再起動するのではなく、すぐにロードします。
coordinatorを使用するように構成されたExporterで構成を更新すると、新しいクエリはcoordinatorに送信され、他のExporterがクエリをロードできるようになります。このように、管理対象サーバのクラスタ全体で、そのメトリック構成を同期しながら保持することができます。

Summary

WebLogic Monitoring Exporterは、Docker/Kubernetes環境でのWebLogic Serverインスタンスのクラスタから、メトリックをエクスポートするプロセスを大幅に簡素化します。MBean名を調べ、正規表現でごにょごにょする必要はありません。また、フィールド名からメトリックラベルを明示的に定義することができ、一貫性を確保するために、従属MBeanのメトリックにそれらの定義を自動的に使用します。
テストでは、CPU使用率が低く、より迅速に応答しており、JMX Exporterと比べてパフォーマンスが大幅に向上しています。以下のグラフで緑色の線がJMX Exporter、黄色の線がWebLogic Monitoring Exporterを表します。

WebLogic Serverのパフォーマンスを監視したいお客様にとって、このWebLogic Monitoring Exporterがお役に立つことを願っています。今後のエントリで、PrometheusとGrafanaを使って取得したデータを監視する方法について詳しく説明する予定です。

[misc.] JJUG CCC 2017 Fall

先週の土曜日、西新宿で開催された、JJUG CCC 2017 Fallで、一コマ(20分枠)を頂戴できたので、AOT(Ahead of Time) コンパイルについてお話することができました。セッションを聴講くださったみなさま、JJUGのみなさま、ありがとうございました。ニッチな内容ゆえに満席になるとは思っていなかったので、非常にびっくりしました。

実際にコードをビルドして実行してみたり、パフォーマンスについてお話するには、明らかに20分では足りませんでしたね(45分枠にしておくんだった)。スライドは、一部を除きSlideShareにUpしています(抜いた一部のスライドは、聴講くださった方だけの「おみやげ」ということで)。



とにもかくにも、Java、特にHotSpotでAOTが利用できるようになっていることを知っていただき、「なんか面白そうだからやってみよう」と興味を持ってもらえたのであれば、今回のプレゼンテーションの目的は果たせたかな、と思っています。

Java 10では、Linux x64だけではなく、macOS、WIndowsでも利用できるようになる予定です。「試してみたい!」という方は、JDK 10 Early Accessビルドを入手して、試してみてください。なおWindowsの場合は、Visual Studioのamd64用link.exeが必要です。

macOS (High Sierra)

[Linux] Running Oracle Linux 5 applications in Oracle Cloud Infrastructure using lxc.

原文はこちら。
https://blogs.oracle.com/wim/running-oracle-linux-5-applications-in-oracle-cloud-infrastructure-using-lxc

Oracle Cloud Infrastructureのベアメタルサーバおよび仮想マシンはEFI対応のOSが必要で、お客様がインスタンスに展開するためにOracle Linux 6とOracle Linux 7イメージを提供しています。ほとんどのアプリケーションはこれらのOSバージョンで動作保証およびサポートされていますが、Oracle Linux 4や5を必要とするような古いアプリケーションをお持ちになる場合もあります。現時点では、これらのバージョンをネイティブインスタンスで実行することはできませんが、Oracle Linux 4やOracle Linux 5環境を持つLinux ContainersをOracle Linux上で実行することは可能です。
長年にわたり、Oracle Linuxでは lxc をサポートしてきました。
Oracle Linux containers
https://blogs.oracle.com/wim/oracle-linux-containers
lxc はシステムコンテナに最適で、OS環境全体(基本的には"start /bin/init")を呼び出すことができますが、それに対しDockerは、アプリケーションの起動、つまりアプリケーション・コンテナです。確かにアプリケーションとして /bin/init を実行することはできますが、 lxc はこのモデルに対して少々チューニングされているます。汎用的なlxcのドキュメントは以下にあります。
Oracle® LinuxAdministrator's Guide for Release 7
Linux Containers
https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-containers.html
lxc はOracle Linux 6および7で完全にサポートされており、Oracle Linux 5はlxc上のコンテナOSとして完全にサポートされています。そのため、OCIのLinuxの古いバージョン上で古いアプリケーションを実行する必要のあるお客様にとっては、これは最適な選択肢です。
Oracle Cloud Infrastructureで lxc を使ってみるためには、
  • まずOSイメージとしてOracle Linux 7を使うベアメタルサーバもしくはVMインスタンスを作成
  • 仮想クラウドネットワークを作成
  • ブロック・ボリュームを作成
  • ブロック・ボリュームのインスタンスへのアタッチ
などの作業が必要で、こうした作業手順に詳しいものとします。あと、追加でVNIC周りでもう一つ仮定を置きます。最も簡単なネットワーク設定は、別々のセカンダリVNICを各コンテナに割り当て、このVNICをコンテナに渡すことです。簡単なチュートリアルは以下にあります。
Tutorial - Launching Your First Linux Instance
https://docs.us-phoenix-1.oraclecloud.com/Content/GSG/Reference/overviewworkflow.htm
作業手順を纏めると以下のようです。
  • コンパートメント、仮想クラウドネットワーク(VCN)、サブネットを作成
  • インスタンス(ベアメタルもしくはVM)を作成
  • コンテナをホストするブロック・ボリュームを作成
  • VNICを作成(コンテナあたり1個)
  • lxc のインストール
  • コンテナを置くブロックボリュームでファイルシステムを作成し、マウント
  • コンテナの作成
lxcをインストールするには、Oracle Linuxインスタンスでyumを使います。
# yum install lxc
...
Dependencies Resolved
================================================================================
 Package         Arch          Version                  Repository         Size
================================================================================
Updating:
 lxc             x86_64        1.1.5-2.0.9.el7          ol7_latest        231 k
Updating for dependencies:
 lxc-libs        x86_64        1.1.5-2.0.9.el7          ol7_latest        219 k
Transaction Summary
================================================================================
Upgrade  1 Package (+1 Dependent package)
Total download size: 450 k
Is this ok [y/d/N]:
lxcの最新バージョン(1.1.5-2.0.9 以上)であることを確認してください。
btrfsをコンテナファイルシステムとして利用するものとします。
ブロックボリュームを作成していれば、/dev/sdbとして確認できるはずです。
Tutorial - Launching Your First Linux Instance
Adding a Block Volume 
https://docs.us-phoenix-1.oraclecloud.com/Content/GSG/Tasks/addingstorage.htm
$ cat /proc/partitions
major minor  #blocks  name
   8        0   48838656 sda
   8        1     556988 sda1
   8        2    8420348 sda2
   8        3   39808260 sda3
   8       16  134217728 sdb
fdiskでパーティションを作成しますが、今回は簡単のためにボリューム全体を使って1個のパーティションを作成します。
$ fdisk /dev/sdb
Enter n (new partition), p (primary partition) 1 (first  partition on new volume) and hit enter twice if you want to use the  entire Block Volume.
Enter w to write the partition table out to disk.
以下のような表示になることでしょう。
$ cat /proc/partitions
major minor  #blocks  name
   8        0   48838656 sda
   8        1     556988 sda1
   8        2    8420348 sda2
   8        3   39808260 sda3
   8       16  134217728 sdb
   8       17  134216704 sdb1
btrfsボリュームを作成し、そのボリュームを/containerにマウントします。
$ mkfs.btrfs /dev/sdb1
$ echo "/dev/sdb1 /container btrfs defaults,noatime,_netdev 0 2" > /etc/fstab
$ mount -a
lxcのインストールで既にサーバの/containerディレクトリを作成しています。
続いて、以下のドキュメントを参照し、スクリプトを使って、2個目のvNICを構成します。Bare Metalインスタンスに対し、VMインスタンスでは少々違いがあります。
Overview of Networking - Virtual Network Interface Cards (VNICs)
https://docs.us-phoenix-1.oraclecloud.com/Content/Network/Tasks/managingVNICs.htm?Highlight=secondary_vnic
1個目のlxcコンテナを作成します。構文は以下の通りです。
lxc-create -n <container name> -t <template> -- -R <release>
  • container nameには利用したいコンテナ名を指定します。例えば、ol5とします。
  • Oracle Linuxコンテナを作成するために、templateとして"oracle"テンプレートを使います。
  • releaseでは、利用したいコンテナOSのリリースを指定します。今回はOracle Linux 5コンテナを作成しているので、-R 5.latest を使います。
  • Oracle Linux 4、6、7の場合、同じ "oracle" テンプレートを使いますが、<release> を4.latest、6.latest、7.latestに変更します。
$ lxc-create -n ol5 -t oracle -- -R 5.latest
Host is OracleServer 7.3
Create configuration file /container/ol5/config
Yum installing release 5.latest for x86_64
...
Added container user:oracle password:oracle
Added container user:root password:root
Container : /container/ol5/rootfs
Config    : /container/ol5/config
Network   : eth0 (veth) on lxcbr0
新規作成したコンテナのネットワーク構成を変更するという、追加の構成が必要です。
コンテナ構成ファイルを変更します。
$ vi /container/ol5/config
このファイルの以下の行
lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:xx:xx:xx <- where xx:xx:xx has assigned values
を、次のように変更します。
lxc.network.type = phys
lxc.network.link = ens2f0.vlan.1  or ens4 or whatever name of the secondary vnic interface created earlier was called
lxc.network.hwaddr の行はコメントアウトもしくは削除します。
#lxc.network.hwaddr =
スクリプトが生成するインターフェースのMACアドレスを利用したいので、hwaddrの行をコメントアウトすることをお奨めします。
直接コンテナに効率的にネットワークインターフェースをパススルーするためにvethをphysに変更します。

コンテナを起動します。
$ lxc-start -n ol5.1
コンソールに接続します。
$ lxc-console -n ol5.1
デフォルトの root パスワードは root です。コンテナ作成後変更してください。
コンソールを終了するには、以下をタイプします。
ctrl-a q
以下のURLを確認すると、コンテナ内のネットワークを構成します。VNICのIP構成をインスタンス内から見つけることができます。
$ wget http://169.254.169.254/opc/v1/vnics/
以下は手作業で実施します。
$ ifconfig eth0 10.0.2.3 netmask 255.255.255.0
$ route add default gw 10.0.2.1
新たにifcfgスクリプトを作成し、起動時にネットワークを構成するようにします。
/etc/sysconfig/network-scripts/ifcfg-eth0 を編集します。編集例は以下の通りです。
DEVICE="eth0"
BOOTPROTO=none
ONBOOT=yes
TYPE="Ethernet"
IPADDR=10.0.2.3
PREFIX=24
GATEWAY=10.0.2.1
DEFROUTE=yes
どのlxcコンテナがアクティブかを確認するには、以下のコマンドを使います。
$ lxc-ls --active
このコンテナはOracle Linux 7上で動作する、サポートされるOracle Linux 5環境ができあがりました。

注:Oracle Linux 5はExtended Supportのフェーズに入っています。詳細は以下をご覧ください。
Oracle Linux 5 Extended Support Data Sheet
http://www.oracle.com/us/technologies/linux/oracle-linux-5-extended-support-3662088.pdf
Oracle Cloud Subscriptionのお客様は、SubscriptionにExtended Supportが含まれています。追加料金や手数料は不要です。

[Linux] Accelerating Linux Boot Time

原文はこちら。
https://blogs.oracle.com/linuxkernel/accelerating-linux-boot-time

このエントリはOracle LinuxカーネルチームのPasha Tatashinによるものです。

Linux Reboot

マシンが速やかに再起動することが重要な理由はたくさんあります。いくつか列挙してみましょう。
  1. 稼働時間と可用性の向上
  2. 顧客体験の向上:ブート/リブートプロセスが速いとマシン全体が速くなったように感じる
  3. ダウンタイムが短くなれば、重要なパッチを迅速に適用してセキュリティを向上させることが可能
上記のすべてが競争上の優位性を提供します。

Linux Early Boot Improvements

今年初めから、Linuxの起動と再起動のパフォーマンスを向上させる方法を検討してきました。これまでのところ、私は初期起動時のみを見ていて、いくつかの問題を特定しました。それらのうちのいくつかはすでにメインラインのLinuxにプッシュされており、一部は統合されている途中です。

ここでは、3064個のCPUと32TBのメモリを搭載した最大規模のSPARCマシンのLinuxの再起動時間を示します(ほとんどの修正は汎用コードに含まれていますが、大規模な構成の他のアーキテクチャでも同様の改善が見込まれます)。

Linux1 (before) Linux2  (after)
Shutdown 4m20s 4m20s
Firmware 1m13s 1m13s
Kernel 14m32s 0m58s
Services 8m44s 4m13s
Total 28m49s 10m44s

Note: 上記の結果に比べ、素のハードウェア上ではファームウェアの初期化は何倍も時間がかかります。このデータは仮想化I/Oを備えたLDomゲストで測定したものです。
  • Linux1は手を入れる前のメインラインカーネルです。
  • Linux2には以下の変更を追加しています。
    1. add_node_ranges() が遅い
      32TBのシステムでは、この関数は82秒を要しています。その理由は、このページが属するNUMAノードを決定するために1ページずつ辿るためです。この関数を最適化すると、1秒未満で完了するようになりました。この成果はすでにメインラインのLinuxに統合されています。
    2. より高速に起動するためにOpenFirmware CPUノードのキャッシュをスキップLinuxはOpenBootからすべてのCPUに関する情報をキャッシュします。そのため、3064個のCPUがあると75.56秒かかります。しかし、ハイパーバイザのマシン記述子にすべて含まれているため、sun4vのCPUノードに関する情報は実際には必要ありません。この修正を適用すると、ブート中にOpenBootからデータをキャッシュするのに1秒未満ですみます。この変更はまだメインラインに提出されていません。
    3. page構造体の並列ゼロ初期化
      起動中にmemblockアロケータが1スレッドだけを使いpage構造体に割り当てられたメモリをゼロ初期化します。この修正では、page構造体の遅延初期化機能を使用して、page構造体のゼロ初期化を並列処理します。この修正により、32Tマシンでは約73秒起動時間を短縮できます。パッチはアップストリームのコミュニティに提出され、現在レビュー中です。
    4. page構造体の遅延初期化の有効化(詳細は後述)
      Linuxには、ブート時にpage構造体の並列初期化オプションがあります。この修正により、起動時間が171秒短縮されます。現在のところ、SPARCではいくつかの依存作業(例えば、メモリのホットプラグ)が完了するまで、このオプションは無効になっています。
    5. 低速ハッシュテーブルの初期化
    6. inode_cachep、dentry_hashtableといった、alloc_large_system_hash()を使って割り当てられたハッシュテーブルは、メモリサイズが増加すると大きくなる可能性があります。これらの多くは単純にmemset()でゼロ埋めすることで初期化できます。また、一部は現在の増大速度ほど速く成長しません。今回、この問題に取り組むために新しい適応型スケーリングアルゴリズム(adaptive scaling algorithm)を追加しました。この修正により、起動時間が58秒短縮します。パッチはメインラインにあります。
    7. 初期ブートタイムスタンプ
      この作業ではパフォーマンスは向上しませんが、上記で見つかった多くの問題を検出できます。

Complete Deferred Page Initialization

システム内のすべての物理ページフレーム(physical page frame)には、関連するpage構造体があり、これを使ってページのステータスを記述します。起動時に、カーネルはすべてのpage構造体にメモリを割り当て、初期化します。従来、初期化はスレーブCPUがオンライン化される前に起動の早い段階で行われるため、大規模なマシンではかなりの時間がかかります。この問題は、Mel GormanがParallel struct page initialisation機能を追加した2015年に部分的に解決されました。
Parallel struct page initialisation v4
http://linux-kernel.2935.n7.nabble.com/PATCH-0-13-Parallel-struct-page-initialisation-v4-tt1094819.html
Melのプロジェクトでは、起動時にカーネルはpageの小さな部分集合のみを初期化し、残りを他のCPUが利用可能なときに初期化していました。ただし、page構造体の初期化時間をさらに短縮するには、次の2つの方法があります。
  1. 初期化を並列実行していたとしても、page構造体が格納されるメモリのゼロ埋めは(これまで同様)1個のスレッドだけを使って実施します。これはLinuxの初期ブートメモリアロケータ(memblock)が割り当て対象のメモリを常にゼロ埋めするためです。この問題を解決するためには、起動時のゼロ埋めを他のCPUが使用可能になった時点で実施するようにすることが必要です。しかし、カーネルのある部分がpage構造体のメモリを初期化またはゼロ埋めすることを期待しているため、複雑な課題に対応する必要があります。そのため、メモリがゼロ埋めされる前に、page構造体にアクセスさせないようにする必要があります。このプロジェクトは現在レビュー中であり、1TBのメモリを搭載するOracle X5-8では起動が22秒早くなります。
    complete deferred page initialization
    https://lwn.net/Articles/734374/
    時間短縮は搭載メモリサイズに比例し、X5-8は最大6TBまで搭載可能なので、フル構成のX5-8ではブート時間は約132秒短縮できます。
    Oracle Server X5-8—Features
    https://www.oracle.com/servers/x86/x5-8/features.html
    このプロジェクトでは、既存のブート時のバグを修正し、今後新しいバグが入り込まないようにするため、memblockアロケータにデバッグチェックを追加しています。
  2. もう一つの、page構造体の初期化を改善するための最適化は、ノードごとに複数のスレッドを使用して構造体ページを初期化することです。1つのメモリノードには、数ギガバイトのメモリを含めることができます。一例として、6TBのメモリを備えたX5-8はノードあたり0.75TBのメモリを持ち、この値は新しいシステムで増加し続けます。新しいXeonプロセッサはノードあたり最大1.5TBをサポートし、AMDのEPYCプロセッサはノードあたり最大2TBをサポートします。
    Intel® Xeon® Platinum 8180M Processor 38.5M Cache, 2.50 GHz
    Product Specifications
    https://ark.intel.com/products/120498/Intel-Xeon-Platinum-8180M-Processor-38_5M-Cache-2_50-GHz
    EPYC™ 7000 Series
    http://www.amd.com/en/products/epyc-7000-series
    EPYC™ 7000 Series Data Sheet
    http://www.amd.com/system/files/2017-06/AMD-EPYC-Data-Sheet.pdf
    Daniel Jordanは、現在レビュー中の彼のktaskの作業にこの最適化を含めました。
    ktask: multithread cpu-intensive kernel work
    https://lwn.net/Articles/731925/
    ktaskについては以下のエントリをご覧ください。
    ktask: A Generic Framework for Parallelizing CPU-Intensive Work
    https://blogs.oracle.com/linuxkernel/ktask%3A-a-generic-framework-for-parallelizing-cpu-intensive-work
    https://orablogs-jp.blogspot.jp/2017/11/ktask-generic-framework-for.html

Early Boot Time Stamps

Linuxには、コンソールに表示される各行の先頭にタイムスタンプを入れるのに便利な機能があります。CONFIG_PRINTK_TIMEはデフォルトで多くのディストリビューションで有効になっています。
CONFIG_PRINTK_TIME: Show timing information on printks
https://cateee.net/lkddb/web-lkddb/PRINTK_TIME.html
これを使えば、dmesg -dコマンド(dmesgの新しいバージョンでのみ-dフラグを利用可)を使用して、起動時および実行時のregressionをすばやく検出できます。
dmesg - print or control the kernel ring buffer
http://man7.org/linux/man-pages/man1/dmesg.1.html
しかし、タイムスタンプはブート時の最終段階で利用できるため、ブートにかなりの時間を費やすと、その時間が報告されません。実際、このエントリで説明しているすべての改善は、printkタイムスタンプが利用可能になる前に発生します。したがって、起動時にタイムスタンプを利用できるようにするために、SPARC用とx86用の2つのプロジェクトで作業が行われました。 SPARCはすでにメインライン上にありますが、x86は現在レビュー中です。
[v3 0/8] Early boot timestamp
https://www.spinics.net/lists/sparclinux/msg18063.html
[PATCH v6 0/4] Early boot time stamps for x86
https://lkml.org/lkml/2017/8/30/574

[Cloud] Announcing Commvault Integration with Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-commvault-integration-with-oracle-cloud-infrastructure-v2

Commvaultの統合とOracle Cloud Infrastructure(OCI)のサポートを発表できわくわくしています。お客様は、Commvaultソフトウェアを使用してバックアップ対象としてOracle Cloud Infrastructure Object Storageを使用できるようになりました。
Oracle Cloud Infrastructure > Storage
https://cloud.oracle.com/ja_JP/infrastructure/storage
Commvaultは、オンプレミスおよびクラウドベースのワークロードにエンタープライズクラスのデータ保護テクノロジを提供します。このコラボレーションにより、管理者がバックアップ、リカバリおよびアーカイブを一貫して管理しながら、Oracle Database、Oracle以外のデータベース、仮想マシン、ファイル、ログなどのすべてのエンタープライズ・ワークロードのバックアップおよびリカバリが可能です。
Commvaultのサポートは、OCI Object Storageとのネイティブな統合に基づいています。Commvaultは、データ重複除外とデータ暗号化においてエンタープライズクラスの機能を提供します。OCI Object Storageに送信する前に、Commvaultを使用してデータを重複排除および暗号化することができます。 Commvaultには完全かつ独立したコピー保持管理機能もあります。Oracle Cloudでクラウド固有の作業負荷を保護する場合、この統合によりオンプレミスおよびクラウド間のツールセットが統合整理され、コストの削減、複雑さの低減、および再トレーニングの労力を最小限に抑えます。

以下はCommvaultでバックアップターゲットとして、OCI Object Storageを構成するために必要なものをまとめたものです。

OCI Object Storage Configuration on Commvault Console

Configure Cloud Storage Library

1. Cloud Storage Libraryの追加


2. OCI Object Storageの構成




Backup and Restore

新たに構成したOCI Object Storageを使ってバックアップやリストアを実行するためには、Storage PolicyとBackup Sub-clientが必要です。

1. ポリシーを右クリックしてStorage Policyをセットアップします。New Storage Policyを選択します。


2. Sub-clientを作成します。


3. Backupを実行します。


4. Job Controllerからバックアップのジョブを監視します。


5. Restoreを実行します。




この統合の目的は、CommvaultをOCI Object Storageのために構成する際にシームレスな体験を提供することにあります。OCI Object Storageの資格証明のセット、つまりObject Storageのエンドポイント、Access KeyとSecret Keyさえあればよいのです。

まずは、オンラインドキュメントやCommvaultの最新のブログエントリをご覧になるところからはじめてください。
Oracle Cloud Infrastructure - Services
Overview of Object Storage
https://docs.us-phoenix-1.oraclecloud.com/Content/Object/Concepts/overview.htm
COMMVAULT SOFTWARE SIMPLIFIES USING ORACLE CLOUD
https://www.commvault.com/blogs/2017/october/commvault-software-simplifies-using-oracle-cloud
データ保護、バックアップ、復元をより簡単に実施できるようにするために、皆様のご意見をお寄せください。

[Linux] ktask: A Generic Framework for Parallelizing CPU-Intensive Work

原文はこちら。
https://blogs.oracle.com/linuxkernel/ktask%3a-a-generic-framework-for-parallelizing-cpu-intensive-work

コアカーネルチームのDaniel Jordanがktaskフレームワークのレビューを書きました。ktaskフレームワークは、Linux Kernelメーリングリストに提出され、現在レビュー中です。

直近ではLinuxカーネルに大きなタスクを並列化させるktaskというプロジェクトに取り組んできました。これらのタスクは常にカーネル・コンテキストで実行されますが、カーネル内で直接開始することも、アプリケーションからシステムコールを通じて間接的に開始することもできます。
このエントリでは、このフレームワークが必要になった課題、フレームワークの背後にあるハイレベルの思想、これまでに実装したユースケース、およびプロジェクトに関するその他の詳細について説明します。最後に、各タスクが効率的に並列化されていることを確認するために使用したLinuxパフォーマンスツールを説明します。

Motivation

コア数やメモリサイズが増えてもアプリケーションとカーネル自体が引き続きうまく稼働するようにするためには、カーネルのスケーリングを行う必要があります。例えば、システムコールがシステムリソースの特定の部分を呼び出す場合、カーネルは同様の割合のシステムリソースを使用して要求に対応するようにして対応する必要があります。 しかし、いくつかの場所では、カーネルがまだ動作していない場合があります。
たとえば、データベースやインメモリ・キャッシュなどの大きなアプリケーションがシャットダウンしてページをシステムに返した場合、そのアプリケーションはマシンのメモリの半分を簡単に使用していた可能性があります。しかし現在のところ、解放されるメモリのサイズにかかわらず、カーネルはこの作業にたった1スレッドを割り当てています。この部分がボトルネックになって、大規模なアプリケーションがすべてのリソースを返すために数分かかってしまい、その間に他のアプリケーションがそれらのリソースを使用することができなくなる可能性があります。

Concept

ktaskとは、これらのタイプの重い要求を処理するために使用されるカーネルスレッドの数をスケーリングするように設計されたものです。
コンセプトはかなりシンプルですが、用語を説明しておきます。タスク(task)とは、実行すべき総作業であり、チャンク(chunk)はスレッドに与えられた作業の単位です。
ktaskフレームワークを使ってタスクを完了するために、(システムコールなどの)カーネル・クライアントが、1つのチャンクを完了させるスレッド関数を提供します。スレッド関数は、クライアントがタスクに固有のデータを渡すために使用する引数だけでなく、チャンクを区切るstart引数とend引数を標準的な方法で定義されます。
さらに、クライアントは、タスクの開始を表すオブジェクトと、タスクのいくつかのユニットを進めて新しいタスク位置を表す別のオブジェクトを生成する方法を知っているイテレータ関数を提供します。ktaskフレームワークは、開始オブジェクトとイテレータを内部的に使用して、タスクをチャンクに分割します。
最後に、クライアントは、1チャンクで処理するのに適した最小作業量を示すために、タスクの合計サイズとチャンクの最小サイズを渡します。サイズはタスク固有の単位(ページ、inode、バイトなど)で与えられます。ktaskフレームワークは、オンラインのCPU個数と内部の最大スレッド数とともに、これらのサイズを使用して、何個のスレッドを開始すべきか、タスクを何個のチャンクに分割すべきかを決定します。
たとえば、巨大なページをクリアするタスクを考えてみると、このタスクは構成要素の各ベースページのページクリア関数を呼び出す 'for'ループを伴う単一のスレッドで行われていました。ktaskを使って並列化するために、クライアントはまずforループをスレッド関数に移動し、関数に渡された範囲で動作するようにします。この単純なケースでは、スレッド関数の開始引数と終了引数は、huge pageの一部をクリアするためのアドレスに過ぎません。次に、 forループが使用されていた箇所で、クライアントは、huge pageの開始アドレス、huge pageの合計サイズ、およびスレッド関数を使用してktaskを呼び出します。内部的には、ktaskはアドレス範囲を適切な数のチャンクに分割し、適切な数のスレッドを開始してそれらを完了します。

インターフェイスの詳細については、最新のアップストリームパッチセットを参照してください。
[RFC PATCH v2 2/7] ktask: multithread cpu-intensive kernel work
https://lkml.org/lkml/2017/8/24/801

Use Cases and Performance Results

これまでのところ、ktaskは、システムが匿名ページを解放するパスのunmap (2) やexit (2) 、ブート時にページの初期化を構成し、最大のhuge pageサイズをゼロにするといった箇所で使用することが予定されています。huge pageをクリアする簡単な例で、ktaskフレームワークのパフォーマンスを説明します。

以下の結果は下表のスペックを持つOracle X5-8 serverで計測しました。
CPU type: Intel(R) Xeon(R) CPU E7-8895 v3 @ 2.60GHz
CPU count: 144 cores (288 threads); 8 nodes @ 18 cores/node
Memory: 1T
以下はテスト結果です。1つのNUMAノード内と、大規模なマルチノードシステム上のすべてのノードにわたるスケーラビリティを示すために、4つのレンジサイズを使用しました。最初のサイズ(100GB)は、完全に同じノードのページから構成されています。サイズが最初のサイズを超えて増加するにつれて、ゼロ初期化されたメモリは増大し、次第にシステムのノードの多くを含んでいきます。
nthread   speedup   size (GiB)   min time (s)   stdev
     1                    100          41.13    0.03
     2     2.03x          100          20.26    0.14
     4     4.28x          100           9.62    0.09
     8     8.39x          100           4.90    0.05
    16    10.44x          100           3.94    0.03

     1                    200          89.68    0.35
     2     2.21x          200          40.64    0.18
     4     4.64x          200          19.33    0.32
     8     8.99x          200           9.98    0.04
    16    11.27x          200           7.96    0.04

     1                    400         188.20    1.57
     2     2.30x          400          81.84    0.09
     4     4.63x          400          40.62    0.26
     8     8.92x          400          21.09    0.50
    16    11.78x          400          15.97    0.25

     1                    800         434.91    1.81
     2     2.54x          800         170.97    1.46
     4     4.98x          800          87.38    1.91
     8    10.15x          800          42.86    2.59
    16    12.99x          800          33.48    0.83
このテストでは最大8スレッドまでスケールしていますが、16スレッドでは壁に当たっています。これはチップのメモリ帯域幅の上限に達したためです。実際には、より多くのスレッドがより多くのチップのキャッシュを使用できるため、2〜8スレッドまでは非常にリニアに高速化していることがわかります。
ここで強調しているループはclear_page_erms という、タイトループ内でわずかな命令を使うプラットフォーム固有のページクリア関数で、1つのスレッドで最高2550 MiB/sの帯域幅に達します。 2スレッド、4スレッド、または8スレッド利用時に各スレッドで同じ帯域幅を得られますが、16スレッドではスレッドごとの帯域幅が1420 MiB/sに低下します。
しかし、ktaskがNUMAを認識することでのパフォーマンスも向上します(ktaskは、実行されている作業のローカルノード上でワーカースレッドを開始します)。このことは性能向上のより大きな要素になります。それは、ゼロ初期化するページの量が複数のノードからのメモリを含んで増大するにつれ、メモリサイズが増加するにつれて実際にスピードアップするという、優れたスケーラビリティの利点を得られからです。

Tools Used to Build this Framework

このフレームワークは、huge pageの消去やmunmap(2)のような、パス最適化時の2つのステップのうちの最初のものに過ぎません。ホットロック、キャッシュラインバウンシング、スレッド間の冗長な作業といった効率的な並列化の障害を取り除くために、カーネルコードをさらにチューニングする必要があります。幸いにもLinuxカーネルには、これらの問題を診断する上で役立つ多くのツールが付属しています。
最も使用したツールはlock_statです。
lock statistics (lock_stat)
https://www.kernel.org/doc/Documentation/locking/lockstat.txt
これは競合カウント、ロックの獲得数、待ち時間といった、さまざまなカーネルのロックに関するメトリックを収集する、ユーザ空間にアクセスできるツールです。lock_statを使用するには、CONFIG_LOCK_STAT=y を指定してカーネルをビルドする必要があります。カーネルからエクスポートされた多くのユーティリティと同様に、lock_statはprocファイルによって制御されます。まず /proc/lock_stat は収集されたデータを表示し、続いて /proc/sys/kernel/lock_stat はツールを有効化または無効化します。このエントリに添付されている単純なラッパースクリプトは、こうした作業をすべて自動化するものです。そのため、スクリプトを実行するだけでよいのです。
lstat cmd...
コマンドが戻ると、 lock_stat が無効化され、/proc/lock_stat をのんびりご覧頂くことができます。将来のシステム動作によってデータが汚れることを心配する必要はありません。-fオプションを使用すると、データをファイルに書き出すことができます。

もう1つの便利なツールは、perf probeで、これはコードを変更せずに動的なトレースポイントを実行中のカーネルに追加できるperfサブコマンドです。
perf-probe(1)
https://raw.githubusercontent.com/torvalds/linux/master/tools/perf/Documentation/perf-probe.txt
今回の場合、workqueueのスレッド待ち時間を調べるために使用しましたが、トレースする特定の関数をトレースしたい場合、一般にperf probeは有用です。どのCPUで関数が実行されたのか、関数(entry、return、さらには特定の命令)内のどの時点でいつ実行されたのかを表示することができます。利用にあたっては、カーネルを以下の設定で構成する必要があります。
CONFIG_KPROBE_EVENTS=y
CONFIG_KPROBES=y
CONFIG_PERF_EVENTS=y
以下は、あらかじめ定義されたイベントと動的プローブを組み合わせて、前述のスレッド待ち時間を測定するperf probeのサンプルです。この実験の目的は、ある状況下で、ktaskクライアントがktask_runを呼び出し、ktaskスレッド関数(ここではdispose_list_task)を実行するまでの間に、workqueueスレッドが原因で大きな遅延になっていないことを検証することでした。dispose_list_task関数はevict2と呼ばれる別の関数を多く呼び出すため、並列化に適しています。perf probeは、このプロセスの各ステップがいつどこで起こったかを示すのに役立ちます。

まず、動的なプローブを冗長に (-v) 追加 (-a) します。
# perf probe -v -a evict_inodes
# perf probe -v -a ktask_run
# perf probe -v -a ktask_task
# perf probe -v -a 'dispose_list_task start:x64 end:x64'             # fourth probe
# perf probe -v -a 'evict2 inode:x64'
# perf probe -v -a 'evict2_ret=evict2+309 inode:x64'                 # sixth probe
# perf probe -v -a 'dispose_list_task_ret=dispose_list_task%return'
# perf probe -v -a 'ktask_task_ret=ktask_task%return'
# perf probe -v -a 'ktask_run_ret=ktask_run%return'
# perf probe -v -a 'evict_inodes_ret=evict_inodes%return'
最初の3つは、カーネルの関数名を使用して、プローブを関数呼び出し時に呼び出すようにします。4番目のプローブdispose_list_taskは、関数呼び出し時にも起動しますが、関数の引数(startおよびend)を64ビットの16進値として出力します。6番目はevict2の特定の命令で呼び出されます。残りのプローブはそれぞれの関数から戻ったタイミングで呼び出されます。

今回は設定したダイナミックプローブを使用して、実際に関心のあるコマンドを記録します。'probe:'という接頭辞が付いていないプローブ(ここでは例えば 'workqueue:' )は、最近のすべてのカーネルに表示されるあらかじめ定義されたperfイベントです。
# perf record -aR                           \   
    -e probe:evict_inodes                   \   
    -e probe:ktask_run                      \   
    -e workqueue:workqueue_queue_work       \   
    -e workqueue:workqueue_activate_work    \   
    -e workqueue:workqueue_execute_start    \   
    -e probe:ktask_task                     \   
    -e probe:dispose_list_task              \   
    -e probe:evict2                         \   
    -e probe:evict2_ret                     \   
    -e probe:dispose_list_task_ret          \   
    -e probe:ktask_task_ret                 \   
    -e workqueue:workqueue_execute_end      \   
    -e probe:ktask_run_ret                  \   
    -e probe:evict_inodes_ret               \     
    cmd...
-aフラグを指定すると、システム内のすべてのCPU上のイベントが記録されます。 通常、perfは与えられたコマンドのイベントだけを記録しますが、この場合はカーネル内のworkqueueスレッドもトレースします。
# chown user:group perf.record.out
root権限で不必要に実行されないようにファイルのパーミッションを変更した後、以下のようにperfレコードから生成されたraw出力を後から処理できます。
$ perf script -F cpu,event,time,trace > perf.script.out
$ cat perf.script.out
[006]        0.000000:                probe:evict_inodes: (ffffffff811f6c20)
[006]        0.014580:                   probe:ktask_run: (ffffffff8107e210)
[006]        0.014584:    workqueue:workqueue_queue_work: work struct=0xffff8818634b6058 function=ktask_task workqueue=0xffff883fef931a00 req_cpu=1 cpu=1
[006]        0.014585: workqueue:workqueue_activate_work: work struct 0xffff8818634b6058
...snip...
[001]        0.014645: workqueue:workqueue_execute_start: work struct 0xffff8818634b6058: function ktask_task
[001]        0.014667:                  probe:ktask_task: (ffffffff8107e0c0)
[001]        0.014671:           probe:dispose_list_task: (ffffffff811f5a50) start_x64=0x0 end_x64=0x1
[001]        0.014673:                      probe:evict2: (ffffffff811f5890) inode_x64=0xffff8818a15fbb50
[001]        0.016089:                  probe:evict2_ret: (ffffffff811f59c5) inode_x64=0xffff8818a15fbb50
[001]        0.016090:                      probe:evict2: (ffffffff811f5890) inode_x64=0xffff881fc9fceb10
[001]        0.017483:                  probe:evict2_ret: (ffffffff811f59c5) inode_x64=0xffff881fc9fceb10
...snip...
[001]        0.193898:                      probe:evict2: (ffffffff811f5890) inode_x64=0xffff8816939c6b10
[001]        0.195335:                  probe:evict2_ret: (ffffffff811f59c5) inode_x64=0xffff8816939c6b10
[001]        0.195339:       probe:dispose_list_task_ret: (ffffffff811f5a50 <- ffffffff8107e134)
[001]        0.195345:           probe:dispose_list_task: (ffffffff811f5a50) start_x64=0x15 end_x64=0x16
[001]        0.195347:                      probe:evict2: (ffffffff811f5890) inode_x64=0xffff8819a55f2350
[001]        0.196753:                  probe:evict2_ret: (ffffffff811f59c5) inode_x64=0xffff8819a55f2350
...snip...
[001]        2.701235:                      probe:evict2: (ffffffff811f5890) inode_x64=0xffff8816fdb52290
[001]        2.702268:                  probe:evict2_ret: (ffffffff811f59c5) inode_x64=0xffff8816fdb52290
[001]        2.702269:       probe:dispose_list_task_ret: (ffffffff811f5a50 <- ffffffff8107e134)
[001]        2.702273:              probe:ktask_task_ret: (ffffffff8107e0c0 <- ffffffff81072c69)
[001]        2.702275:   workqueue:workqueue_execute_end: work struct 0xffff8818634b6058
...snip...
[006]        2.706126:               probe:ktask_run_ret: (ffffffff8107e210 <- ffffffff811f6e0a)
[006]        2.706129:            probe:evict_inodes_ret: (ffffffff811f6c20 <- ffffffff811db4b4)
左から、括弧内のCPU番号、秒単位のイベントのタイムスタンプ、プローブ名が並んでいます。リクエストした追加のデータは、行末に表示されます。この例では、ktask_runの呼び出しから1スレッドの最初のチャンクの開始時間(probe : dispose_list_task)が100マイクロ秒(0.014671 - 0.014580)未満であったことがわかりました。これから、workqueueスレッドの待ち時間が問題ではないことがわかります。

最後に、システムから動的トレースポイントを削除します。
# perf probe -d '*'

Conclusion

このエントリで、ktaskのモチベーションとなったスケーラビリティに関する問題、フレームワークのコンセプト、ユースケースを説明し、最後にフレームワーク作成時に使用したパフォーマンスツールについてまとめました。
これからは、ktaskに対するより多くのフィードバックをいただき、より多くのCallerを追加し、コアフレームワークを強化し続けることを計画しています。ktaskが近い将来、アップストリームに進出し、すべての人がカーネルスケーラビリティの向上を享受できるようになることを願っています。