[Cloud] Introducing Email Delivery on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/introducing-email-delivery-on-oracle-cloud-infrastructure

このエントリはSarah Galler(Principal Product Manager, Oracle Cloud Infrastructure)が寄稿しました。

Oracle Cloud InfrastructureプラットフォームでEmail Delivery(電子メール配信)が可能になりました。簡単に言えば、Email Deliveryを利用すれば、顧客のアプリケーションが電子メールを送信し、より高い成功率で意図したオーディエンスに到達できるようになります。Email Deliveryは、Oracle Dynの優れたEmail Deliveryサービスをベースに構築され、 U.S. Westリージョン(アリゾナ州フェニックス)で利用可能です。
Oracle + Dyn
https://dyn.com/
Oracle + Dyn - Email Delivery Service
https://dyn.com/email/
どの地域のお客様も、Email Deliveryサービスを使用して電子メールを配信できます。他の地域も近日利用可能になる予定です。

電子メールの量が年々増加し続けているにもかかわらず、意図した相手の受信トレイに電子メールを送信することは、評判の高い送信者にとっても依然として大きな課題であり続けています。Oracle Cloud Infrastructure Email Deliveryを使用すると、信頼性、スケーラビリティ、使いやすさのために、その課題は指数関数的に簡単になります。10年以上にわたって、Oracle Dynは、業界で最もクリーンなクラウドベースのネットワークの1つを使用して、メール配信の課題を解決しました。クリーンなネットワークはよりよい評判につながり、結果として電子メール配信のより高い成功率に繋がります。

Email Deliveryは、ビジネス上重要な情報を顧客やユーザーに提供するために使用されるサービスです。これらのアクティビティには、購買領収書、パスワードリセット、welcomeメールなどのトランザクション通知が含まれます。結論として、Oracle Cloud Infrastructure Email Deliveryは、お客様に対してポジティブなエンド・ユーザー体験を提供します。

このリリースでは以下の機能を提供します。
  • SMTP(Simple Mail Transfer Protocol、電子メール送信のインターネット標準)経由の送信
  • Sender Policy Framework(SPF) - インターネットプロトコル(IP)が明示的にそのドメインに対し送信する権限を持っているかどうかをチェックすることで、電子メール受信者が電子メールのなりすましを検出できます。
  • Suppression List Management(抑制リスト管理) - 重大なバウンスや苦情のアドレスは自動的に抑制リストに追加され、コンソールまたはAPIを介して表示および管理できます。
Email Deliveryのサービス概要ビデオのリンクはこちら。


CAPEXやリソース、カスタムでのメール配信システム開発の複雑性を排除します。Oracle Cloud Infrastructure Email Deliveryがどのように今日の企業に役立つかについては、以下のページをご覧ください。
Enterprise DNS Service Features
https://cloud.oracle.com/en_US/edge
今後のエントリでは、特定のユースケースを掘り下げて、電子メール配信の設定と利点についてご紹介する予定です。

[WLS, Java, Database] Ensuring high level of performance with WebLogic JDBC

原文はこちら。
https://blogs.oracle.com/weblogicserver/ensuring-high-level-of-performance-with-weblogic-jdbc

原文はLaurent Goldsztejnによるものですが、Joseph Weinsteinが追加情報やコードサンプルを追加しています。
このエントリでは、WebLogic JDBCで高パフォーマンスを保証するためのベストプラクティスを紹介します。

Use WebLogic DataSources for connection pooling of JDBC connections

    実際にDBMS接続を作成するのは高コストで遅いので、データソースを使用して接続を保持し再利用するべきです。プールされた接続を使用する理想的なモードは、できるだけ迅速かつ短時間で使用し、必要なときにそれらを取得し、できるだけ早くそれらを閉じる(プールに戻す)ことです。これにより並行性が最大化されます。
    connection(接続)がメソッドレベルのオブジェクトであり、アプリケーションスレッド間で共有されず、アプリケーションコードの終了パスに関係なくクローズされることが重要です。そうしないと、プールから接続がリークし、すべての接続が取り出されて放棄されてしまいます。
    このエントリのベストプラクティスのコードサンプルを見てください。 WebLogic Datasourcesとアプリケーションやその他のWebLogic APIの長期的な強化と統合により、UCPやサードパーティのオプションに優先して選択できます。

    Use Oracle JDBC thin driver (Type 4) rather than OCI driver (Type 2)

      Oracle JDBC Thinドライバは、軽量(インストールと管理が容易)、プラットフォーム非依存(Javaで記述)、JDBC OCI(Oracle Call Interface)ドライバよりもわずかに高いパフォーマンスを提供します。Thinドライバは、クライアントサイドで追加ソフトウェアを必要としません。Oracle JDBCのFAQでは、Thinドライバのパフォーマンス上の利点が一貫していないこと、およびOCIドライバが一部のシナリオでより優れたパフォーマンスを提供できることも規定されています。WebLogicでOCIを使用すると、ネイティブ・ライブラリのバグによってWebLogic Server全体が停止する危険性があります。

      Use PreparedStatements objects rather than plain Statements 

        PreparedStatementsを使うと、コンパイル済SQLクエリプランはDBMSキャッシュに保持され、一度解析された後に再利用されます。

        Use/configure the WebLogic Datasource’s statement cache size wisely.

          データソースはキャッシュでき、プールされた接続から作成されたPrepared/CallableStatementを透過的に再利用できます。プールのステートメント・キャッシュサイズ(デフォルトは10)でその数を決定します。これはいくらかのメモリを必要としますが、たいていの場合、パフォーマンスが向上します。ただし、least recently usedポリシーではキャッシュサイズをパージするので、例えばデータソースを使用するアプリケーションが通常30個の個別のPreparedStatementを作成する場合、次回のリクエストごとに新しいステートメントがキャッシュに置かれ、以前利用された10個のステートメントは放り出されるため、ステートメントの再利用はできません。コンソールでは、いくつかのステートメントキャッシュ統計を使用して、すべてのステートメントを処理するようにキャッシュのサイズを設定できるようにしますが、メモリーが大きな問題になる場合は、キャッシュサイズをゼロに設定する方が良い場合があります。

          Close all JDBC resources ASAP, inline, and for safety, verify so in a finally block

            これには、LOBs、ResultSets、Statements、およびConnectionsオブジェクトが含まれ、メモリを最大限に活用しながら、特定のDBMSサイドのリソースの問題を回避します。仕様により、Connection.close()はそこからすべてのサブオブジェクトを閉じる必要があります。また、close()のWebLogicバージョンは実際の接続をプールに戻しながらクローズすることを意図していますが、一部のオブジェクトは、別のドライバで異なる実装になっている可能性があり、その実装ではWebLogicにすべてを解放させないかもしれません。LOBsなどのJDBCオブジェクトが正しく閉じられないと、以下のエラーが発生する可能性があります。
            java.sql.SQLException: ORA-01000: maximum open cursors exceeded.
            StatementとResultSetsを明示的に速やかに閉じないと、カーソルが蓄積され、接続を閉じる前にデータベースが許容する最大数を超えることがあります。

            以下はWebLogic JDBCのベストプラクティスのコード例です。
            (訳注)今ならtry-with-resourcesで書くでしょうし、例外を握りつぶしているのがなんともあれですが、原文のままにしています。

            public void myTopLevelJDBCMethod() {
                // メソッドレベルのオブジェクトとして定義され、他のスレッドが使用できる場所にはアクセスできない、もしくは保持されない。
                Connection c = null; 
            
                // JDBC利用にあたっての事前準備
            
                // このメソッド(およびサブメソッド)のすべてのJDBC操作が実行されるtryブロック
                try {
                  // WLSデータソースから直接接続を取得
                  c = myDatasource.getConnection();
            
                  // Connectionをサブメソッドに渡すことができるが、サブメソッドはConnectionを保持してはいけない。
                  // メソッドの終了後にConnectionがオープン/実行可能であることをオブジェクトまたはオブジェクトのいずれかから期待されている
                  doMyJDBCSubTaskWith( c );
            
                  // JDBC操作が終了したらすみやかに接続をクローズする
                  c.close(); 
            
                  //finallyブロックでConnectionが取得された場合でもクローズされたことがわかる
                  c = null; 
            
                  // JDBCを必要としないものは残しておいてもかまわない。
                  // JDBCとは関係ないデータの後処理を行う前にConnectionをできるだけ早く閉じると、
                  // 同時実行性が大きく向上する
                } catch (Exception e) {
            
                  // catchブロックが必要であればここに必要なロジックを記述する。
                  // ただし、finallyブロックは必ず配置しておく
            
                } finally {
                   // 接続を閉じずにここまで到達したら、finallyブロックの最初に以下を必ず実行する
                  If (c != null) try {c.close();} catch (Exception ignore){}
            
                  // finallyブロックに記述したいコード
                }
            }
            

            Set The Datasource Shrink frequency to 0 for fastest connection availability

            現在の負荷が不十分(想定よりも小さい)である場合、データソースの不要な部分(最小容量より大きい)を閉じて実際の接続数を変更するように設定でき、さらに、必要に応じて再作成されますが、これにより新しい置き換えの接続が作成されている間、負荷の上昇中にアプリケーションの速度が低下します。縮小率をゼロに設定することにより、データソースはすべての利用可能な接続を無期限に準備完了状態に保ちます。これは、あまりにも多くのアイドルセッションがある場合、DBMSのトレードオフになることがあります。

            Set the datasource test frequency to something infrequent or zero

            データソースは、アプリケーション負荷とは無関係に、現在使用されていない接続、プール内でアイドル状態の接続、不良な接続の置き換えなどを定期的にテストするように設定できます。これには、アクティブでない場合に接続を切断する可能性のあるファイアウォールやDBMSに対し、接続がビジー状態に見えるようにするなど、いくつかの利点があります。ただし、これはWLSのオーバーヘッドであり、必要に応じて予約時に接続をテスト(test connections on reserve)していれば、ほとんどの場合不要です。

            Consider skipping the SQL-query connection test on reserve sometimes

            予約時に接続をテストする機能は常にONにしておくべきです。というのも、DBMSの健全性に関するActive GridLinkの情報があっても、個々の接続が悪くなる可能性があるため、取得しようとしている接続が良好な状態であることを確実にする唯一の方法は、データソースを取得しようとしている直前にデータソーステストを行うことです。しかし、毎回この接続テストを実施するにはコストが高すぎる場合があります。具体的には短時間のユーザーユースケースに対して余計な時間が加わってしまうか、DBMSに負担がかかりすぎるためです。このような場合で、アプリケーションが時には不正な接続を取得することが多少許容される場合、データソースオプション「アイドル・プール接続を信頼する秒数」(デフォルトは10秒)があります。これは、信頼する秒数の間にプール内の接続が正常にテストされた場合、またはアプリケーションによって以前に正常に使用された場合、その接続を信頼し、それをテストせずにリクエスタに渡します。負荷が重く、回転が速い環境では、テストの明示的なオーバーヘッドを安全かつ完全に回避できます。

            Consider making the test as lightweight as possible

            データソースの 'Test Table'(テスト対象の表名)パラメータが設定されている場合、プールはそのテーブルから 'select * from'を実行して接続をテストします。DUALはOracle Databaseの場合における伝統的な選択です。JDBCのisValid()呼び出しを使用するオプションもあります。これはドライバによっては高速な場合があります。例えばOracle Databaseのdbping()の場合、実際にユーザーレベルのDBMS機能を呼び出さずにto-DBMSのネット接続をチェックします。高速ではあるものの、接続上は良好であったとしても、まれにユーザーセッション機能が壊れていることがあります。XA接続の場合、より大きなトレードオフです。テストテーブルへのクエリはそれ自身のXAトランザクション内で実行されますが、これはより大きなオーバーヘッドですが、次のユーザーXAトランザクションが失敗するようなセッションステートの問題を見つけ、回避して動作する上で有用なことがあります。

            Consider enabling Pinned-to-Thread

            デフォルトで無効になっています。このオプションは、特定のWLSスレッドにプール接続を透過的に割り当てることで、パフォーマンスを向上させることができます。これにより、データソースにアクセスする際にスレッド間の競合がなくなります。ただしpinned-to-thread(スレッドに固定)を有効にすると接続プールの最大容量が無視されるため、このパラメータは、細心の注意を払って使用する必要があります。各スレッド(おそらく数百)は独自のconnectionを必要とし、取得します。そのため、そのプールを縮小することはできません。

            Match the Maximum Thread Constraint property with the maximum capacity of database connections

            このプロパティ(コンソールのEnvironment Work Managerを参照)は、同時実行可能なアプリケーション・スレッド/実行の最大数を設定します。アプリケーションが並列実行できる場合、このWebLogicの制限以外に制限がない場合には、データソースの最大容量はこのスレッド数と一致する必要があります。したがって、他のスレッドから接続が返されるまで、アプリケーションスレッドは空のプールで待機する必要はありません。

            WebLogic Serverでシステムパフォーマンスを向上するためのJDBCデータ・ソースおよび接続プールでの追加のパラメータ・チューニングについては、以下のドキュメントをご覧ください。
            Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.3.0)
            データ・ソース接続プールのチューニング
            https://docs.oracle.com/cd/E92951_01/wls/JDBCA/ds_tuning.htm
            Oracle® Fusion Middleware Administering JDBC Data Sources for Oracle WebLogic Server 12c (12.2.1.3.0)
            Tuning Data Source Connection Pools
            https://docs.oracle.com/middleware/12213/wls/JDBCA/ds_tuning.htm
            アプリケーション固有の設計や構成については以下のドキュメントをご覧ください。
            Oracle® Fusion Middleware Oracle WebLogic Server JDBCアプリケーションの開発 12c (12.2.1.3.0)
            JDBCアプリケーションのパフォーマンス・チューニング
            https://docs.oracle.com/cd/E92951_01/wls/JDBCP/performance.htm
            Oracle® Fusion Middleware Developing JDBC Applications for Oracle WebLogic Server 12c (12.2.1.3.0)
            Performance Tuning Your JDBC Application
            https://docs.oracle.com/middleware/12213/wls/JDBCP/performance.htm

            [Linux] Oracle Linux 7 UEK5 (Linux kernel 4.14) sneak preview

            原文はこちら。
            https://blogs.oracle.com/wim/oracle-linux-7-uek5-linux-kernel-414-sneak-preview

            次期kernel-uekの最初のプレビューバージョンをリリースしました。これはアップストリームカーネル4.14 (latest stable -14) をベースにしています(UEK4はアップストリームカーネル4.1をベースにしています)。
            試してみたいという方は以下のyumリポジトリをOracle Linux 7ベースのシステムに追加するだけでOKです。OL7の環境をすぐに用意できない場合には、Oracle Cloudの無料アカウントにサインアップし、Oracle Linux 7インスタンスを迅速に作成できますので、その後は同様にyumリポジトリを追加してください。
            このプレビュー版カーネルは定期的にアップデートされますので、開発の成果の最新情報を得ることができます。ソースコードもあり、github/oracle にgitリポジトリをまもなくPushする予定です。
            利用する側が実施することは、以下のスニペットを/etc/yum.repos.d/public-yum-ol7.repoファイルに追加するだけです。
            [ol7_developer_UEKR5]
            name=Oracle Linux $releasever UEK5 Development Packages ($basearch)
            baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/developer_UEKR5/$basearch/
            gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
            gpgcheck=1
            enabled=1
            
            その後、カーネルをアップグレードします。
            yum upgrade kernel-uek
            
            再起動しておしまいです。
            最新の dtrace を一緒に試したい場合は、同じリポジトリに入っていますので、以下のようにインストールしてください。
            yum install dtrace-utils
            
            dtrace -lを実行すると、5000個委譲のプローブがあることがわかることでしょう。

            [Linux] Announcing Software Collections 3.0

            原文はこちら。
            https://blogs.oracle.com/linux/announcing-software-collections-30

            Unbreakable Linux NetworkおよびOracle Linux yumサーバーへのSoftware Collections 3.0のリリースしたことを発表しました。
            Unbreakable Linux Network
            https://linux.oracle.com/
            Oracle Linux yum server
            http://yum.oracle.com/
            Software Collectionsは、主に、Perl、PHP、Pythonなどのソフトウェアコンポーネントの最新機能にアクセスする必要がある開発環境向けです。これらの環境では、これらのコンポーネントのバージョンに依存するシステムプロセスの中断を最小限に抑える必要があります。Software Collectionsライブラリを使用すると、同じソフトウェアの複数のバージョンをシステムに同時にインストールして使用することができます。その際プロセスを中断する必要はありません。
            Software collectionsライブラリユーティリティ(scl)を使用して、インストール済みのSoftware collectionsから開発者ツールを実行します。sclユーティリティは、インストール済みの同じソフトウェアユーティリティの他のバージョンの実行の影響を受けないようにします。

            New Software Collections for Oracle Linux 7

            以下のコレクションがSoftware Collections for Oracle Linux 7に追加されました。
            • devtoolset-7
            • rh-maven35
            • rh-nginx112
            • rh-nodejs8
            • rh-php71
            Oracle Linux 7をご利用の方はOracle Linux 7ドキュメントライブラリのSoftware Collection Library 3.0 for Oracle Linux 7のリリースノートで詳細をご確認ください。
            Software Collection Library 3.0 for Oracle® Linux Release Notes
            https://docs.oracle.com/cd/E52668_01/E59096/html/index.html
            Oracle Linux 7 documentation library
            https://docs.oracle.com/cd/E52668_01/index.html

            New Software Collections for Oracle Linux 6

            Oracle Linux 6のSoftware Collectionsに以下のコレクションが追加されました。
            • devtoolset-7
            • rh-python36
            Oracle Linux 6をご利用の方は、Oracle Linux 6ドキュメントライブラリのSoftware Collection Library 3.0 for Oracle Linux 6のリリースノートで詳細をご確認ください。
            Software Collection Library 3.0 for Oracle Linux 6 Release Notes
            https://docs.oracle.com/cd/E37670_01/E59096/html/index.html
            Oracle Linux 6 documentation library
            https://docs.oracle.com/cd/E37670_01/index.html

            Support

            Software CollectionsのサポートはOracle Linux Premier Support契約に含まれており、サブスクリプション契約されているお客様は追加コストなくご利用いただけます。
            有償サポートをご利用でない場合には、Oracle Communityフォーラムでのピア・サポートをご利用いただけます。
            Oracle Developer Community Forum
            https://community.oracle.com

            [Linux] Using RDS with ipv6 Networks

            原文はこちら。
            https://blogs.oracle.com/linuxkernel/using-rds-with-ipv6-networks

            RDSとは、Oracleが開発し、Linuxカーネルに寄贈したオープンソースのReliable Datagram Socketsプロトコルです。カーネル開発者のKa-Cheong Poonが、RDSをipv6対応させるための彼の作業をまとめています。

            現在、RDSはIPv4アドレスを使用するピア間でしか動作できません。IPv6が世界中で普及しているので、IPv6アドレスを使用するピア間でRDSを動作させる必要性がますます高まっています。その要求に対応するため、Oracle Linux RDSをアップデートし、IPv6をサポートするようにました。この記事では、RDSを利用するC言語で書かれた既存のアプリケーションを、IPv6をサポートするように変更する方法について説明します。基本的なIPv6 APIについては、RFC 3493を参照してください。RFC 4291では、IPv6アドレス指定アーキテクチャについて説明しています。また、rds-toolsパッケージもアップデートして、IPv6をサポートするようにしました。いくつかの使用例もご紹介します。
            RDS Wire Specification 3.1
            https://oss.oracle.com/projects/rds/dist/documentation/rds-3.1-spec.htmlState of IPv6 Deployment 2017
            https://www.internetsociety.org/resources/doc/2017/state-of-ipv6-deployment-2017/Basic Socket Interface Extensions for IPv6
            https://tools.ietf.org/html/rfc3493IP Version 6 Addressing Architecture
            https://tools.ietf.org/html/rfc4291
            RDSのIPv6サポートは、アプリケーションに対する最小限の変更でIPv6をサポートするよう設計されています。前述のように、次の呼び出しはRDSソケットを作成します。
            int sd;
            sd = socket(AF_RDS, SOCK_SEQPACKET, 0);
            作成されたソケットは、IPv4またはIPv6アドレスを使用しピアとの通信に使用できます。これは、ソケットが作成時にアドレスファミリの指定が必要なTCPソケットとは少し異なります。では、いつこのRDSソケットをIPv6 RDSソケットに変更するのでしょうか?この説明の前に、アドレス処理の説明を簡単にするために、以下のような共用体を定義しましょう。
            union sockaddr_ip {
                struct sockaddr_in      addr4;
                struct sockaddr_in6     addr6;
            };
            この共用体は、IPv4アドレスまたはIPv6アドレスのいずれかを格納するために使用できます。アプリケーションがユーザーが提供するローカルアドレスでユーザーが提供するピアアドレスと通信する必要がある場合、次のコードを使って提供されたバッファーを解析できます。
            char *user_suuplied_laddr, *user_supplied_paddr;
            struct addrinfo *ainfo;
            union sockaddr_ip local_addr, peer_addr;
            socklen_t local_addrlen, peer_addrlen;
            
            if (getaddrinfo(user_supplied_laddr, NULL, NULL, &ainfo) != 0) {
                /* Error handling code */
            } else {
                /* Just use the first one returned. */
                local_addrlen = ainfo->ai_addrlen;
                memcpy(&local_addr, ainfo->ai_addr, local_addrlen);
                freeaddrinfo(ainfo);
                ...
            }
            if (getaddrinfo(user_supplied_paddr, NULL, NULL, &ainfo) != 0) {
                /* Error handling code */
            } else {
                /* Just use the first one returned. */
                peer_addrlen = ainfo->ai_addrlen;
                memcpy(&dst_addr, ainfo->ai_addr, peer_addrlen);
                freeaddrinfo(ainfo);
                ...
            }
            /* The following checks for address family mismatched.  Note that the
             * address family field of all socket address structures are at the same
             * position.  Hence we can use sin_family to do the check.
             */
            if (local_addr.addr4.sin_family != peer_addr.addr4.sin_family) {
                /* Error handling code */
            }
            getaddrinfo(3)関数は、IPv4とIPv6の両方のアドレスを認識し、正しい情報でアドレスを埋めます。

            ピアと通信する前に、まずRDSソケットをバインドする必要があります。これは以下のように行います。
            if (bind(sd, (struct sockaddr *)local_addr, local_addrlen) != 0) {
                /* Error handling code */
            }
            ユーザーがIPv4アドレスを指定した場合、RDSソケットはIPv4 RDSソケットになり、ユーザーがIPv6アドレスを提供した場合、RDSソケットはIPv6ソケットになります。したがって、RDSソケットのファミリはバインド時に決まります。また、RDSソケットは一度しかバインドできないことにご注意ください。(そのため) 2回目のbind()は失敗します。これは、一度RDSソケットのアドレスファミリを設定すると、変更できないことを意味します。また、RDSソケットは同じファミリのピアとしか通信できません。これは上記のアドレスファミリーのチェックで不一致になる理由です。

            (これで)アプリケーションは、以下のようにピアと対話できるようになりました。
            char *msg;
            size_t msg_len;
            
            if (sendto(sd, msg, msg_len, 0, (struct sockaddr *)peer_addr, peer_addrlen) < 0) {
                /* Error handling code */
            }
            アプリケーションが同じソケットを使い別のピアと通信することもできます。 新しいピアアドレスがバインドされたアドレスと同じファミリでなければならないことに注意してください。前述のように、getsockname()を使用してソケットにバインドされたアドレスを取得できます。
            union sockaddr_ip ipaddr;
            socklen_t addrlen;
            
            if (getsockname(sd, (struct sockaddr *)ipaddr, &addrlen) < 0) {
                /* Error handling code */
            }
            ソケットがまだバインドされていない場合、返されるアドレスファミリはAF_UNSPECです。これは、アドレスがバインド済みか否かの判断に使用できます。ソケットはIPv4アドレスまたはIPv6アドレスのいずれかにバインドできるため、ここではユニオンsockaddr_ip共用体の使用に注意してください。

            まとめると、IPv6アドレスを使用するようにRDSアプリケーションを変更するには、IPアドレスを格納するために使用されるソケットアドレス構造とそのソケットアドレス構造を格納するために使用するコードを変更する必要があります。 アドレス構造体を変更すると、他のソケット呼び出しはすべて以前とほぼ同じです。

            rds-tools package

            rds-toolsパッケージには、rds-info、rds-ping、rds-stressという3つのツールが含まれており、これらもIPv6をサポートするようにアップデートされています。以下はその使用例です。

            rds-ping

            ホストAでは
            [host-a]> ip addr show ib0
            9: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 4096
                link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0a:79:fd brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
                inet6 2010:211::12/64 scope global
                   valid_lft forever preferred_lft forever
                inet6 fe80::202:c903:a:79fd/64 scope link
                   valid_lft forever preferred_lft forever
            そしてホストBでは
            [host-b]> ip addr show ib0
            6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 4096
                link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0a:75:a5 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
                inet6 2010:211::22/64 scope global
                   valid_lft forever preferred_lft forever
                inet6 fe80::202:c903:a:75a5/64 scope link
                   valid_lft forever preferred_lft forever
            であると仮定します。
            以下のように、rds-pingを使って両ホスト間のIPv6でのRDSの到達可能性をテストできます。
            [host-a]# rds-ping fe80::202:c903:a:75a5%ib0
               1: 160 usec
               2: 155 usec
               ...
            fe80::202:c903:a:75a5 はホストBのIPv6リンクローカルアドレスです。リンクローカルアドレスはインターフェイスに関連付ける必要があるため、アドレスの後に%ib0(またはこの場合は%9)を配置して、ib0を使用してそのリンクローカルアドレスに到達するように指定する必要があります。 ホストBからも可能です。
            [host-b]# rds-ping 2010:211::12
               1: 162 usec
               2: 153 usec
            ...
            この例では、ホストAのグローバルアドレスをテストしています。IPv6グローバルアドレスの場合インターフェースを指定する必要はありません。

            rds-info

            rds-infoのデフォルト出力には変更ありません。これは、下位互換性を保つためにIPv6接続情報がデフォルトで表示されないことを意味します。IPv6接続情報を表示するには、「-a」オプションを使用します。 このオプションで、IPv4とIPv6の両方の情報を表示します。rds-pingの例を引き続き使用することにしますが、ホストAで上記を行った後、rds-infoを使用してRDSの接続状態を確認できます
            [host-a]# /tmp/rds-info -Ina
            RDS IB Connections:
                        LocalAddr            RemoteAddr  Tos  SL         LocalDev        RemoteDev
                     2010:211::12          2010:211::22    0   0      fe80::2:c903:a:79fd      fe80::2:c903:a:75a5
                fe80::202:c903:a:79fd     fe80::202:c903:a:75a5    0   0      fe80::2:c903:a:79fd      fe80::2:c903:a:75a5
             
            RDS Connections:
                        LocalAddr            RemoteAddr  Tos   NextTX   NextRX Flgs
                     2010:211::12          2010:211::22    0    5    5 --C-
                fe80::202:c903:a:79fd     fe80::202:c903:a:75a5    0       11       11 --C-
            上図は、ホストAに2つのRDS接続があることを示しています(1つはホストAとBのグローバルアドレス間の接続、もう1つはホストAとBのリンクローカルアドレス間の接続)。InfiniBandインターフェイスを使用しているため、2つのIB接続もあります。IPv6情報のみが存在するため、"-a"オプションを指定しないと何も表示されません。

            rds-stress

            アドレスオプション "-s"と "-r"で、IPv6アドレスをとることができるようになりました。 以下は利用例です。
            [host-a]> rds-stress -r 2010:211::12
            waiting for incoming connection on 2010:211::12:4000
            accepted connection from 2010:211::22::41735
            negotiated options, tasks will start in 2 seconds
            Starting up....
              ...
            [host-b]> rds-stress -r 2010:211::22 -s 2010:211::12
            connecting to 2010:211::12:4000
            negotiated options, tasks will start in 2 seconds
            Starting up....
            ...
            アップデートされたrds-stressは新旧rds-stressのいずれとも通信できます。

            [Cloud] Announcing Packer Builder for Oracle Cloud Infrastructure Classic

            原文はこちら。
            https://blogs.oracle.com/developers/announcing-packer-builder-for-oracle-cloud-infrastructure-classic

            HashiCorp Packer 1.2.0 がOracle Cloud Infrastructure Classic上のイメージ構築をネイティブサポートするようになりました。
            HashiCorp Packer
            https://www.packer.io/
            Change Log : 1.2.0
            https://github.com/hashicorp/packer/blob/master/CHANGELOG.md#120-february-9-2018
            Packerは、単一のソース構成から複数のプラットフォームにわたるマシンイメージを作成するためのオープンソースツールです。新しいoracle-classicbuilderを使用すると、oracle-oci Builderと同様に、直接Oracle Classic Compute上に新しいアプリケーション・イメージを構築できます。
            Oracle Cloud Infrastructure Classic Compute Builder
            https://www.packer.io/docs/builders/oracle-classic.html
            Oracle Cloud Infrastructure (OCI) Builder
            https://www.packer.io/docs/builders/oracle-oci.html
            新しいイメージは、Oracle提供の基本OSイメージ、既存のプライベート・イメージ、またはOracle Cloud Marketplaceからインストールされたイメージから作成できます。
            Oracle Cloud Marketplace
            https://cloudmarketplace.oracle.com/marketplace/compute
            (注意)
            PackerはVirtualBoxビルダーを使い、Oracle Cloud Infrastructure Classic互換のマシンイメージを作成することもできます。そしてこの方法は、新たなベースOSイメージをISOイメージから構築する場合に今なお有用です。詳細は以下をご覧ください。
            Creating Oracle Compute Cloud Virtual Machine Images using Packer
            https://blogs.oracle.com/cloudmarketplace/creating-oracle-compute-cloud-virtual-machine-images-using-packer

            oracle-classic Builder Example

            この例では、既存のUbuntuイメージをベースOSとして使用し、Redisをインストールした新たなイメージを作成します。
            packer構成ファイルを作成します(redis.json)。
            {
              "builders": [
                {
                  "type": "oracle-classic",
                  "username": "user@example.com",
                  "password": "PASSWORD",
                  "identity_domain": "a12345678",
                  "api_endpoint": "https://api-z27.compute.us6.oraclecloud.com/",
                  "shape": "oc3",
                  "image_name": "Redis_{{timestamp}}",
                  "source_image_list": "/Compute-a12345678/user@example.com/Ubuntu.16.04.20180122.amd64",
                  "dest_image_list": "Redis",
                  "image_description": "Redis Image Built with Packer",
                  "ssh_username": "opc",
                }
              ],
              "provisioners": [
                {
                  "type": "shell",
                  "inline": [
                    "sudo apt-get update",
                    "sudo apt-get install -y redis-server"
                  ]
                }
              ]
            }
            
            Packerを実行してイメージを構築します。
            $ packer build redis.json


            Packerの動作が完了後、新しいイメージがCompute Classicコンソールで利用可能になっており、新規インスタンスを立ち上げることができます。

            See also

            Oracle Cloud Infrastructureイメージ作成にあたっては、以下をご覧ください。

            [misc.] Tech Deep Dive #2 の参加受付を開始しました

            2018年3月17日(土)、Tech Deep Diveは大阪にお出かけします。

            どうしても大阪でやりたかったので、非常にうれしいです。もちろん、開催だけではなく、たくさんの方々にご参加いただきたいと思っています。土曜日なので、家族サービスやその他諸々あるかもしれませんが、ご興味ある方はぜひご参加ください。
            内容は、 #0 でやった内容に加え、アプリケーション開発者からみたデータベースというお話です。「データベースはインフラの人がよろしくやってくれるから…」という考えの方もいらっしゃるかもしれませんが、ちょっと知っておくといいことがあると思いますよ。
            スピーカーは、OTNの記事「もしもみなみんがDBをクラウドで動かしてみたら」でも有名なみなみん(@minamin96)、そしていとうちひろ(@chiroito)です。ロジ子はお約束通り、裏方です。

            [Virtualization] Announcing the Oracle Vagrant boxes GitHub repository

            原文はこちら。
            https://blogs.oracle.com/developers/announcing-the-oracle-vagrant-boxes-github-repository

            本日OracleソフトウェアのVagrant環境を作成するための新たなGitHubリポジトリを発表しました。
            vagrant-boxes
            https://github.com/oracle/vagrant-boxes
            Vagrantは開発者向けの環境のセットアップを簡単かつ完全自動化できます。Oracle VirtualBoxとともに、Vagrantは仮想マシン内にサンドボックス環境を作成するための強力なツールです。この発表とともに、労力を掛けずにOracleソフトウェアを完全に構成済みの状態で仮想マシンを作成し、利用できる状態にするという、この強力な自動化を世界中のユーザーにご案内します。これは、開発者の生活をより簡単に、より生産的にするための一連のステップの1つです。

            簡単かつ迅速に始めることができます。まだやったことがない場合は、以下のソフトウェアをダウンロード、インストールする必要があります。
            上記2個のコンポーネントをインストールしたら、GitHubリポジトリをクローン/ダウンロードしてご自身のVagrant環境を作成できます。Oracle Linux仮想マシンを作成する場合、以下のように非常に簡単です。

            1. GitHubリポジトリをクローン(もしくはダウンロード)

            gvenzl-mac:vagrant gvenzl$ git clone https://github.com/oracle/vagrant-boxes
            Cloning into 'vagrant-boxes'...
            remote: Counting objects: 74, done.
            remote: Total 74 (delta 0), reused 0 (delta 0), pack-reused 74
            Unpacking objects: 100% (74/74), done.
            

            2. OracleLinuxというサブフォルダに移動

            gvenzl-mac:vagrant gvenzl$ cd vagrant-boxes/OracleLinux/
            

            3. vagrant upと叩いて、VMのプロビジョニングを待つ

            gvenzl-mac:OracleLinux gvenzl$ vagrant up
            Bringing machine 'default' up with 'virtualbox' provider...
            ==> default: Box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' could not be found. Attempting to find and install...
                default: Box Provider: virtualbox
                default: Box Version: >= 0
            ==> default: Box file was not detected as metadata. Adding it directly...
            ==> default: Adding box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' (v0) for provider: virtualbox
                default: Downloading: http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box
            ==> default: Successfully added box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' (v0) for 'virtualbox'!
            ==> default: Importing base box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box'...
            ==> default: Matching MAC address for NAT networking...
            ==> default: Setting the name of the VM: ol7-vagrant
            ==> default: Clearing any previously set network interfaces...
            ==> default: Preparing network interfaces based on configuration...
                default: Adapter 1: nat
            ==> default: Forwarding ports...
                default: 22 (guest) => 2220 (host) (adapter 1)
                default: 22 (guest) => 2222 (host) (adapter 1)
            ==> default: Running 'pre-boot' VM customizations...
            ==> default: Booting VM...
            ==> default: Waiting for machine to boot. This may take a few minutes...
                default: SSH address: 127.0.0.1:2222
                default: SSH username: vagrant
                default: SSH auth method: private key
                default:
                default: Vagrant insecure key detected. Vagrant will automatically replace
                default: this with a newly generated keypair for better security.
                default:
                default: Inserting generated public key within guest...
                default: Removing insecure key from the guest if it's present...
                default: Key inserted! Disconnecting and reconnecting using new SSH key...
            ==> default: Machine booted and ready!
            ...
            ...
            ...
            ==> default: INSTALLER: Locale set
            ==> default: INSTALLER: Installation complete, Oracle Linux ready to use!
            
            仮想マシンがプロビジョニングされたら、準備完了です。"vagrant ssh"と叩いて仮想マシンにSSHでログインし、やりたいタスクを実行するだけです。終了したら、SSHターミナルの場合と同様に、  "exit" と叩くだけです。
            gvenzl-mac:OracleLinux gvenzl$ vagrant ssh
            
            Welcome to Oracle Linux Server release 7.4 (GNU/Linux 4.1.12-112.14.13.el7uek.x86_64)
            
            The Oracle Linux End-User License Agreement can be viewed here:
            
            * /usr/share/eula/eula.en_US
            
            For additional packages, updates, documentation and community help, see:
            
            * http://yum.oracle.com/
            
            [vagrant@ol7-vagrant ~]$ uname -a
            Linux ol7-vagrant 4.1.12-112.14.13.el7uek.x86_64 #2 SMP Thu Jan 18 11:38:29 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
            [vagrant@ol7-vagrant ~]$ exit
            logout
            Connection to 127.0.0.1 closed.
            gvenzl-mac:OracleLinux gvenzl$
            
            You can stop the virtual machine and reboot it any time by typing “vagrant halt” and “vagrant up”:
            gvenzl-mac:OracleLinux gvenzl$ vagrant halt
            ==> default: Attempting graceful shutdown of VM...
            
            
            gvenzl-mac:OracleLinux gvenzl$ vagrant up
            Bringing machine 'default' up with 'virtualbox' provider...
            ==> default: Clearing any previously set forwarded ports...
            ==> default: Clearing any previously set network interfaces...
            ==> default: Preparing network interfaces based on configuration...
            default: Adapter 1: nat
            ==> default: Forwarding ports...
            default: 22 (guest) => 2220 (host) (adapter 1)
            default: 22 (guest) => 2222 (host) (adapter 1)
            ==> default: Running 'pre-boot' VM customizations...
            ==> default: Booting VM...
            ==> default: Waiting for machine to boot. This may take a few minutes...
            default: SSH address: 127.0.0.1:2222
            default: SSH username: vagrant
            default: SSH auth method: private key
            ==> default: Machine booted and ready!
            [default] GuestAdditions 5.1.30 running --- OK.
            ==> default: Checking for guest additions in VM...
            ==> default: Setting hostname...
            ==> default: Mounting shared folders...
            default: /vagrant => /Users/gvenzl/Downloads/vagrant/vagrant-boxes/OracleLinux
            ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
            ==> default: flag to force provisioning. Provisioners marked to run always will still run.
            gvenzl-mac:OracleLinux gvenzl$
            
            Last最後に、VMをマシンから完全に削除したい場合は、"vagrant destroy"とするだけです。これでVMとその中のもの一切合切削除されますので、このコマンドを使う場合にはご注意を。
            gvenzl-mac:OracleLinux gvenzl$ vagrant destroy
            default: Are you sure you want to destroy the 'default' VM? [y/N] y
            ==> default: Forcing shutdown of VM...
            ==> default: Destroying VM and associated drives... 
            今後Oracleは、より多くのVagrant構成ファイルをこのGitHubリポジトリにUpしていきます。これは、完全なオープンソースの方式で推進していきます。GitHubのIssueを使ってコメントや改善要求をお知らせください。

            Oracle VM VirtualBoxとVagrantを使用したDockerサンドボックスを設定する方法を紹介する、Sergio Leunissenの以下の素敵な動画もチェックしてください。

            [Java] Java 10リリースを約1ヶ月後に控えて

            6ヶ月ごとのリリースに移行したJavaは、来月(2018/3/20)Java 10がリリースされる予定です。
            リリース予定の機能やスケジュールなどは以下をご覧ください。現在Release Candidateフェーズ(リリースにあたって障害となる不具合の修正のみ実施)に入っています。
            JDK 10
            http://openjdk.java.net/projects/jdk/10/
            JDK 10 Early Accessのリリースノート
            http://jdk.java.net/10/release-notes
            Java APIのドキュメントもEarly Access版が公開されています。
            Java® Platform, Standard Edition & Java Development Kit Version 10 API Specification
            https://download.java.net/java/jdk10/docs/api/overview-summary.html
            Java 10での新機能をまとめたエントリも出てきましたね。ぜひ、チェックしてみてください。

            [WLS, Docker] Announcing the New WebLogic Server Kubernetes Operator

            原文はこちら。
            https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operator

            Oracle WebLogic Server Kubernetes Operatorのテクノロジープレビュー版をオープンソースとしてリリースすることを発表できうれしく思っています。Kubernetes上でWebLogic Server 12.2.1.3ドメインを作成および管理するためのこのOperatorをGitHubにリリースするとともに、以下の内容について詳しく説明するブログを公開しています。
            Oracle WebLogic Server Kubernetes Operator
            https://github.com/oracle/weblogic-kubernetes-operator
            Announcing the Oracle WebLogic Server Kuberentes Operator
            https://blogs.oracle.com/developers/announcing-oracle-weblogic-server-kuberentes-operator
            • Operatorの実行方法
            • Kubernetesで1つ以上のWebLogicドメインの起動方法
            • WebLogic診断フレームワーク(WLDF)またはPrometheusを使用し、WebLogicクラスタの手動もしくは自動でスケールアウト・スケールインするする方法
            • OperatorによるWebLogicクラスタにデプロイされたWebアプリケーションの負荷分散の管理方法
            • ElasticSearch、logstash、およびKibanaを使用してOperatorのログを管理するための連携方法
            Kubernetes Operatorは、「Kubernetes APIを拡張して複雑なアプリケーションのインスタンスを作成、構成、管理するための、アプリケーション固有のコントローラ」です。
            Operatorパターンを採用し、これを使用してWebLogic ServerとKubernetesを統合するアダプタを提供しています。これにより、KubernetesをWebLogic Serverインスタンスをホストするコンテナインフラストラクチャとして機能させることができます。したがって、WebLogic Server Kubernetes Operatorは、Kubernetesを拡張してWebLogicドメインの作成、構成、管理を行うオペレータです。

            Operatorは、標準のOracle WebLogic Server 12.2.1.3 Dockerイメージを使用します。このDockerイメージは、Docker StoreまたはOracle Container Registryにあります。
            Docker Store
            https://store.docker.com/
            Oracle Container Registry
            https://container-registry.oracle.com/
            このイメージは不変(immutable)であるとみなされ、すべてのアプリケーションおよび製品のランタイムの状態はKubernetesの永続ボリュームに保持されます。これにより(ランタイムの状態がPod内に存在しないため)、すべてのPodを使い捨てで置き換え可能として扱うことができ、実行時にDockerコンテナに書き込まれた、ランタイムの状態を管理する必要性が完全に無くなります。
            Oracle WebLogic Server Kubernetes Operatorの前提条件は以下の通りです。
            • Kubernetes 1.7.5+, 1.8.0+ (kubectl versionで確認)
            • Flannel networking v0.9.1-amd64 (docker images | grep flannelで確認)
            • Docker 17.03.1.ce (docker versionで確認)
            • Oracle WebLogic Server 12.2.1.3
            My Oracle SupportのドキュメントID 2349228.1で詳しく説明されているように、Kubernetes上のWebLogic Server 12.2.1.3ドメインは動作保証されており、サポート対象です。
            WebLogic Server 12.2.1.3 Certification on Kubernetes (Doc ID 2349228.1)
            https://support.oracle.com/rs?type=doc&id=2349228.1
            WebLogic Kubernetes Operatorはテクニカルプレビュー版であり、Oracle Supportではまだサポートされていません。WebLogic Kubernetes Operatorに関する問題が発生した場合は、以下のGitHubプロジェクトでIssueを開く必要があります。GitHubのプロジェクトメンバーは、問題に迅速に対応し、問題を解決します。
            Issues - Oracle WebLogic Server Kubernetes Operator
            https://github.com/oracle/weblogic-kubernetes-operator/issues
            Operatorのビデオデモンストレーションは以下からご覧いただけます。
            • インストール方法とOperatorのREST APIの利用方法
            • 2個のWebLogicドメインを作成(WebLogic Server管理コンソールにアクセスし、Kubernetesで作成された様々なリソース(サービス、Ingress、Pod、ロードバランサなど)の確認を含む)
            • Webアプリケーションのデプロイ、Operatorを使ったWebLogicクラスタのスケーリング、負荷分散の検証
            • Kubernetesで実行中のドメインに対してWLSTを使用し、同様にKubernetesで動作するOracle Databaseに対するデータソースを作成
            • WLDFを使ったWebLogicクラスタのスケール
            • Prometheus integration - WebLogic ServerのメトリックをPrometheusにエクスポートし、スケール操作を呼び出すためのPrometheusアラートの作成
            Operatorのインストールと構成、およびOperatorを使ったWebLogicドメインの管理にの全体的なプロセスは、以下の手順で構成されています。提供するスクリプトでこれらの手順のほとんどを実行しますが、一部手作業による実行が必要があるものもあります。
            • Oracle Container Registryへのアクセスのための登録
            • Oracle Container Registryにアクセスするためのシークレットの設定
            • Operatorのパラメータファイルのカスタマイズ
            • KubernetesクラスタへのOperatorのデプロイ
            • 管理サーバーの資格証明に対するシークレットの設定
            • WebLogicドメインの永続ボリュームの作成
            • ドメイン・パラメータ・ファイルのカスタマイズ
            • WebLogicドメインの作成
            最新の手順については、以下のURLを参照してください。
            Installation - Oracle WebLogic Server Kubernetes Operator
            https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md
            まもなくこのOperatorへの正式なサポートが提供され、時間の経過とともに新しい機能や拡張機能が追加される予定です。WebLogic Server Kubernetes Operatorの詳細はしばしお待ちください。今回の発表は、KubernetesにWebLogic Serverを導入しようとしている人にとって有益な情報であることを願っております。皆さんのご意見をお待ちしております。

            [Java] EE4J: An Update

            原文はこちら。
            https://blogs.oracle.com/theaquarium/ee4j%3a-an-update

            Eclipse FoundationのMike Milinkovichが先頃自身のブログで全体的なEE4Jプロジェクトの状況を伝えています。
            EE4J: Current Status and What’s Next
            https://mmilinkov.wordpress.com/2018/01/23/ee4j-current-status-and-whats-next/
            • 下記URLで示すコミュニティプロセスを使用し、新しいブランド名の定義作業を進めています。
              Brand Name Selection
              https://github.com/eclipse-ee4j/ee4j/issues/1
            • We have begun the process of moving Oracle GlassFishのソースをEE4Jプロジェクトへ移管するプロセスを開始しました。
              Eclipse Enterprise for Java
              https://projects.eclipse.org/projects/ee4j
              これまでに、Oracleは以下のプロジェクトのソースを提供しています。
              • Eclipse Grizzly
              • Eclipse OpenMQ
              • Eclipse Project for JAX-RS
              • Eclipse Project for JMS
              • Eclipse Tyrus
              • Eclipse Project for WebSocket
              • Eclipse Project for JSON Processing
            • 上記プロジェクトに加え、
              • Eclipse YassonとEclipseLinkプロジェクトがEE4Jに移管され、現在EE4Jプロジェクトの一部になっています。
              • We have created Eclipse JerseyとEclipse Mojarraプロジェクトを作成し、現在これらのソースの提供に取り組んでいます。
            • EE4Jプロジェクトのリポジトリは、EE4JというGitHubの組織で作成しており、EE4Jプロジェクトのリポジトリをご覧いただけます(そしてStarを付けることもできます)。
              Eclipse EE4J
              https://github.com/eclipse-ee4j
            • Oracleは、Mikeが彼のエントリで言及しているすべてのテクノロジー(JSON-B API、Concurrency、セキュリティ、JTA、JavaMail、JAX-B、JAX-WS、JSTL、UEL、JAF、Enterprise Management、およびCommon Annotations)に関するEclipseプロジェクトの提案に取り組んでおり、これらのプロジェクトを早急にEE4J Project Management Committee(PMC)に正式に提案する予定です。
              EE4J PMC and Project Leadership
              https://projects.eclipse.org/projects/ee4j/pmc
              直近の重要な目標の1つは、Oracleが有するGlassFishテクノロジーをすべてEE4Jに移行し、EE4JのソースからEclipse GlassFishを構築し、Java EE 8準拠を実証できるようにすることです。
            • EE4Jにメンバー指向のガバナンスモデルを提供するためのEclipse Foundationワーキンググループの設立に取り組んでいます。
            まとめると、EE4Jプロジェクトは着実に進んでいます。さらなるアップデートについては、このブログと上記のリンクを参照するか、ee4j-communityメーリングリストに登録して入手してください。
            ee4j-community mailing list
            https://dev.eclipse.org/mhonarc/lists/ee4j-community/

            [Linux] XFS - What's new and what's next!

            原文はこちら。
            https://blogs.oracle.com/linuxkernel/xfs-whats-new-and-whats-next

            上流のXFSメンテナンス者であり、Oracle Linuxのカーネル開発者であるDarrick Wongが、XFSに関する1年間の作業の回想を書きました。この中で、最新のLinuxカーネルに登場しているいくつかの素晴らしい機能を暗示しています。(個人的には)オンラインファイルシステムのチェックに期待しています。

            昨年、Linux 4.8-4.9で導入され、昨年のこのブログのエントリで取り上げた新しいリバース・マッピングとreflinkの機能を安定させるために大部分の時間を費やしました。
            Upcoming XFS Work in Linux v4.8 v4.9 and v4.10+, by Darrick Wong
            https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-linux-v48-v49-and-v410%2c-by-darrick-wong
            2018年中頃にreflinkからEXPERIMENTALタグを削除する準備をしています。これにより、より良い拡張性を得るために、in-core file extent map cacheを再作成する必要があります。昨年1月にVFSブロックマッピングインターフェイスをiomapに変換しました。3つのIOアクセス方式(バッファ付き、直接、DAX)はすべて、NVMeフラッシュ上でのオーバーヘッドの削減とパフォーマンスの向上のメリットがあります。

            Linux 4.12では、XFSとext4の両方にGETFSMAP ioctlを導入し、ユーザ空間の管理ツールでファイルシステム空間マップ全体を照会できるようにしました。これにより、システム管理者は、メタデータのオーバーヘッドや空き領域の断片化など、ファイルシステム状態のライブ分析を実行できます。XFSでは、新しいxfs_spacemanでこの機能を提供しますが、ext4では、e2fsprogs 1.43.5のe2freefragツールが、マウントされたファイルシステムの検出時にライブクエリを実行するようになっています。 xfsprogsのリリースはカーネルの後になりました。

            2017年まで、XFS用のオンラインfsckツールの準備に取り組んできました。既存のXFSコードベースには、メタデータバッファがディスクから読み込まれ、ディスクに書き出される前に、メタデータバッファのスポットチェックを実行する単純なメタデータブロックベリファイア(metadata block verifiers)があります。これらのベリファイアはIOホットパス(IO hot path)に存在するため、スコープが非常に限られています。これらは計算コストの高いチェックは実行できません。具体的には、他のメタデータ構造を相互参照することはできません。書き込みパスのエラーではファイルシステムをシャットダウンします。
            こうした課題に対する解決策として、別のオンラインfsckユーティリティがあります。このツールは、ユーザ空間で計算コストの高いチェックをスケジュールし、すべてのチェックで高いコストにならないようにすることで、ベリファイアを拡張します。専用のオンラインfsckツールは、メタデータ値が正確に正しいことを確認することができます。単におおよその範囲内に収まっているかだけをチェックするわけではありません。この最も顕著な例は、逆参照マッピングを使用したブロック参照カウントのチェックです。逆のマッピングツリーを数回歩かなければなりません。他のメタデータと相互参照できる他のすべてもチェックされます。例えば、ファイルデータの範囲が与えられれば、それはinodeではなく、空き領域ではなく、btreeの一部ではなく、拡張属性データとクロスリンクされていないことを保証できます。この種のチェックでは、多くのIOが必要ですが、ユーザー空間ドライバープログラムからIOを管理し、抑制できます。スクラブ作業の一環として、XFSベリファイアを再構成して、破損が見つかった場所をより正確にレポートし、メモリ内バッファの破損を検出するようにします。

            オンラインファイルシステム修復は、スクラブ後にしばらくしてから始まりますが、実行可能な修復戦略がメタデータの最初からの再構築しかないため、このタイプの修復は非常に困難です。これを行うには、ファイルシステム全体のすべてのメタデータをロックしてスキャンし、すべての新しいレコードをメモリに作成し、ディスクに書き出す必要があります。続いて、メモリ内の状態すべてを注意深くリセットする必要があります。

            Linux 4.15にはスクラブの最初の部分が含まれていましたが、それ以降のリリースでは残りの部分が含まれていました。この機能は一度安定すると、ファイルシステムのダウンタイムをさらに短縮できます。

            Allison Hendersonは、XFS親ポインタパッチセットの開発を最近再開しました。XFS親ポインタパッチセットを使うと、拡張属性を設定することで、親ディレクトリのディレクトリエントリへのバックリンクをファイルが記録できます。これにはまず、拡張属性の操作のアトミック性を改良する必要があります。ユーザー空間にフェイルバック可能な通常のファイル属性の操作とは異なり、親ポインタの操作は成功しなければなりません。そうでない場合はファイルシステムが破損しています。親ポインタが配置されたら、オンラインfsckツールを使用してディレクトリツリーの双方向チェックを実行し、ディレクトリを再構築できます。また、書き込みエラーを解決し、影響を受けるファイルパスとオフセットを含むより豊富なログメッセージに記述できるようになります。

            将来的には、これらの新しいストレージメディアへの望ましいユーザー空間インターフェイスを詳細に議論できれば、DAXと永続メモリのサポートが改善されるでしょう。この件はメーリングリスト上で多くの議論を呼び起こしましたが、使用モデルやハードウェアは遅れて現れました。mkfsに対して提案された変更があります。これはディストリビューションや管理者が、mke2fsのように、設定ファイルにデフォルトのmkfsオプションを提供できるようにするものです。古いリアルタイムボリュームを再利用して、メタデータと小さなファイルをSSDに保存しながら、SMRドライブにアーカイブデータを記録できるXFSを構築するためのパッチセットも提案されています。

            2018年にテクニカルプレビューとして登場予定のすべてのXFSの機能にご期待ください。

            [WLS, Docker] T3 RMI Communication for WebLogic Server Running on Kubernetes

            原文はこちら。
            https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes

            Overview

            Oracle WebLogic ServerはJava EEをサポートしており、そしていくつかのベンダー固有の機能強化を含んでいます。それは、Java EEベースのIIOP、RMIという2個のRMI実装に加え、WebLogic ServerがT3と呼ばれる独自のRMIプロトコルです。このエントリではT3にも当てはまる汎用的なRMIの構成と、WebLogic ServerをKubernetesで動作させる上でT3固有の部分を説明します。

            Background

            T3 RMIは、WebLogic Server独自の高性能RMIプロトコルであり、WebLogic Server内部での主要な通信コンポーネントであり、JMS、EJB、OAMなどのサービスの外部でも使用されます。WebLogic ServerのT3 RMI構成が進化しました。これは、デフォルトのチャネルとして知られているWebLogic Server上の単一のマルチプロトコルリスンポートとリスンアドレスで始まります。ネットワークアクセスポイントレイヤーを追加することでデフォルトのチャネルが強化されました。これにより、ユーザーは複数のポートを設定できるほか、カスタムチャネルと呼ばれるポートごとに異なるプロトコルも設定できます。 WebLogic ServerがKubernetes上で動作している場合、WebLogic Serverのリスンポート番号は、Kubernetes公開ポート番号と同じでも異なっていてもかまいません。Kubernetes上で実行されているWebLogic Serverでは、カスタムチャネルを使用して、この2つのポート番号をマッピングできるからです。
            下表は、このブログで使用されている重要な用語を纏めたものです。詳細を確認するためのドキュメントへのリンクも付けています。
            用語
            Listen port WebLogic Serverが物理的にバインドしているTCP/IPポート
            Public port パブリックポート。
            呼び出し側がT3 URLを定義する際に使うポート番号。ポートマッピングを使った接続でない限り、通常はリスンポートと同じ。
            Port mapping とあるアドレスとポート番号の組合せからの通信リクエストを別のものにリダイレクトするネットワークアドレス変換(Network Address Translation、NAT)のアプリケーション。
            Default channel すべてのWebLogic Serverドメインが自動生成する、すべてのWebLogic Serverが有するデフォルトチャネル。
            Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の管理 12c (12.2.1.3.0)
            デフォルト・ネットワーク・チャネル
            https://docs.oracle.com/cd/E92951_01/wls/CNFGD/network.htm#CNFGD167
            Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1.3.0)
            The Default Network Channel
            https://docs.oracle.com/middleware/12213/wls/CNFGD/network.htm#CNFGD167
            Custom channel 異なる種類のネットワークトラフィックを分離するために利用
            ServerTemplateMBean デフォルトチャネルとしても知られる。詳細は以下を参照。
            Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
            Interface ServerTemplateMBean
            https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ServerTemplateMBean.html
            NetworkAccessPointMBean カスタムチャネルとしても知られる。詳細は以下を参照。
            Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
            Interface NetworkAccessPointMBean
            https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/NetworkAccessPointMBean.html
            WebLogic cluster communication クラスタに属するWebLogic Serverインスタンスはマルチキャスト、ユニキャストの2個の基本ネットワークテクノロジーのうちいずれかを使ってお互いに通信する。マルチキャストとユニキャストについては以下を参照。
            Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0)
            クラスタでの通信
            https://docs.oracle.com/cd/E92951_01/wls/CLUST/features.htm#CLUST127
            Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0)
            Communications In a Cluster
            https://docs.oracle.com/middleware/12213/wls/CLUST/features.htm#CLUST127
            WebLogic transaction coordinator トランザクションコーディネータとして振る舞うWebLogic Serverトランザクションマネージャ
            Kubernetes service Kubernetes conceptsを参照。
            Kubernetes Concepts - Services
            https://kubernetes.io/docs/concepts/services-networking/service/
            これはKubernetesのバックエンドとNodePortを定義する。
            Kubernetes pod IP address Podがどのホスト上にあるかに関わらず、KubernetesはPodが他のPodと通信することを想定している。各PodにクラスタプライベートIPアドレスを付与するので、明示的にPod間のリンクやコンテナのポートとホストのポートとのマッピングを作成する必要はない。詳細は以下を参照。
            Kubernetes Concepts - Cluster Networking
            https://kubernetes.io/docs/concepts/cluster-administration/networking/
            ClusterMBean ClusterBroadcastChannelを参照。
            Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
            Interface ClusterMBean
            https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ClusterMBean.html

            WebLogic Server Listen Address

            WebLogic Serverは、マルチキャストとユニキャストの2つのクラスタメッセージングプロトコルをサポートしています。WebLogic Server on Kubernetesの動作保証の検証は、Flannelネットワークファブリックを使用して行われました。 現在、ユニキャスト通信のみを動作保証しています。
            デフォルトでは、WebLogic Serverはユニキャスト通信にデフォルトチャネルを使用します。ユーザーは、関連付けられたWebLogic Server ClusterMBeanにカスタムチャネルを設定することでオーバーライドできます。
            WebLogicクラスタのユニキャスト構成の一環として、WebLogicクラスタメンバーがお互いを発見できるよう、クラスタメンバーごとに指定されたリスンアドレスとポートが必要です。 既定では、既定のチャネルまたはカスタムチャネルはnullリスンアドレスを持ち、実行時に0.0.0.0として割り当てられます。マルチノードKubernetesクラスタ環境では、0.0.0.0とlocalhostのどちらを使っても、異なるノードの他のクラスタメンバが互いに発見できませんが、その代わりに、WebLogic Serverインスタンスが実行されているKubernetes Pod IPアドレスを使用できます。

            TCP Load Balancing

            一般に、WebLogic T3はTCP/IPベースであるため、複数のバックエンドを持つKubernetesサービスなど、サービスが同種の場合にTCP負荷分散をサポートできます。WebLogic Serverでは、JMSやEJBなどのいくつかのサブシステムが同種のものです。例えば、JMSフロントエンドサブシステムは、リモートJMSクライアントが任意のクラスタメンバーに接続できるWebLogicクラスタで構成できますが、対照的に、JTAサブシステムでは、単一のKubernetesクラスタを超えて広がる複数のWebLogicドメインにまたがるトランザクションでTCPロードバランシングを安全に使用できません。JTAトランザクションコーディネータは、トランザクションがコミットまたはロールバックされたときに、トランザクションのサブコーディネータとして選択されたサーバインスタンスへの直接RMI接続を確立する必要があるからです。
            下図は、T3プロトコルを使用してサブコーディネータに接続するWebLogicトランザクションコーディネータを示しています。WebLogicトランザクションコーディネータは、TCPロードバランシングが原因で、選択したサブコーディネータに接続できません。
            Figure 1: Kubernetes Cluster with Load Balancing Service
            Kubernetes環境全体のWebLogicトランザクションコーディネータとトランザクションサブコーディネータ間のクラスタ通信をサポートするには、各デフォルトチャネルとカスタムチャネルに対して個別のNodePortサービスを定義することをお勧めします。
            Figure 2: Kubernetes Cluster with One-on-One Service
            アプリケーションの要件と使用するWebLogicサブシステムに応じて、TCPロードバランシングが適している場合と適切でない場合があります。

            Port Mapping and Address Mapping

            WebLogic Serverは、2つのスタイルのT3 RMIの構成をサポートしています。1つはデフォルトチャネル(ServerTemplateMBeanを参照)によって定義され、もう1つはカスタムチャネル(NetworkAccessPointMBeanを参照)によって定義されるものです。
            Oracle Fusion Middleware MBean Reference for Oracle WebLogic Server 12.2.1.3.0 MBean Reference
            ServerTemplateMBean
            https://docs.oracle.com/middleware/12213/wls/WLMBR/mbeans/ServerTemplateMBean.htmlNetworkAccessPointMBean
            https://docs.oracle.com/middleware/12213/wls/WLMBR/core/index.html
            KubernetesでWebLogic Serverを実行する場合は、ポートマッピングに特に注意する必要があります。
            NodePortを使用してKubernetesクラスタ外でWebLogic T3 RMIサービスを公開する場合は、NodePortをWebLogic Serverのリスンポートにマップする必要があります。NodePortがWebLogic Serverのリスンポートと同じであれば、WebLogic Serverのデフォルトチャネルを使用できます。それ以外の場合は、NodePortのnodePort値と一致する「パブリックポート」と、NodePortのポート値と一致する「リスンポート」を定義するカスタムチャネルを設定する必要があります。
            下図は動作しないNodePort/デフォルトチャネルの構成と、動作するNodePort/カスタムチャネルの構成を示したものです。
            Figure 3: T3 External Clients in K8S
            下表はデフォルトチャネルのプロパティと、それに対応するカスタムチャネルのプロパティを対比したものです。
            Default Channel (ServerTemplateMBean) Custom Channel (NetworkAccessPointMBean)
            複数のプロトコルをサポート(T3、HTTP、SNMP、LDAPなど) Yes No
            RMI over HTTP tunneling Yes
            (デフォルトでは無効)
            Yes
            (デフォルトでは無効)
            Port mapping No Yes
            Address Yes Yes

            Examples of WebLogic T3 RMI configurations

            WebLogic Serverは複数のT3 RMIの構成方法をサポートしています。以下はよく使われる方法の例です。

            Using the WebLogic Server Administration Console

            以下のコンソールページは、リスンポートとして9001、リスンアドレスは無指定、SSLポートの設定をしていない、管理サーバーのWebLogic Serverインスタンスの例です。このサーバーインスタンスをデフォルトチャネルを使って構成しているため、ポート9001はT3、http、iiop、snmp、そしてldapをサポートします。
            Figure 4: T3 RMI via ServerTemplateMBean on WebLogic console
            以下のコンソールページは、リスニングポートとして7010、リスニングアドレスは無指定、パブリックポート30010へのマッピングがなされているカスタムチャネルの例です。デフォルトでは、カスタムチャネルはT3プロトコルをサポートします。
            Figure 5: T3 RMI via NetworkAccessPointMBean on WebLogic Console

            Using WebLogic RESTful management services

            以下のシェルスクリプトはリスンポートとして${CHANNEL_PORT}、ペアとなるパブリックポートとして${CHANNEL_PUBLIC_PORT}を持つカスタムチャネルを作成します。
            #!/bin/sh
            
            HOST=$1
            PORT=$2
            USER=$3
            PASSWORD=$4
            CHANNEL=$5
            CHANNEL_PORT=$6
            CHANNEL_PUBLIC_PORT=$7
            
            echo "Rest EndPoint URL http://${HOST}:${PORT}/management/weblogic/latest/edit"
            if [ $# -eq 0 ]; then
            echo "Please specify HOST, PORT, USER, PASSWORD CHANNEL CHANNEL_PORT CHANNEL_PUBLIC_PORT"
            exit 1
            fi
            
            # Start edit
            curl -j --noproxy '*' --silent \
            --user $USER:$PASSWORD \
            -H X-Requested-By:MyClient \
            -H Accept:application/json \
            -H Content-Type:application/json \
            -d "{}" \
            -X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/startEdit
            
            # Create
            curl -j --noproxy '*' --silent \
            --user $USER:$PASSWORD \
            -H X-Requested-By:MyClient \
            -H Accept:application/json \
            -H Content-Type:application/json \
            -d "{
            name: '${CHANNEL}'
            }" \
            -X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints
            
            curl -j --noproxy '*' --silent \
            --user $USER:$PASSWORD \
            -H X-Requested-By:MyClient \
            -H Accept:application/json \
            -H Content-Type:application/json \
            -d "{
            listenPort: ${CHANNEL_PORT},
            publicPort: ${CHANNEL_PUBLIC_PORT}
            }" \
            -X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints/${CHANNEL}
            
            curl -j --noproxy '*' --silent \
            --user $USER:$PASSWORD \
            -H X-Requested-By:MyClient \
            -H Accept:application/json \
            -H Content-Type:application/json \
            -d "{}" \
            -X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/activate
            

            Using a WLST script

            以下のWLSTスクリプトではt3Channelという名前のカスタムT3チャネルを作成します。これはリスンポートとしてlisten_port、パブリックポートとしてpublic_portを持ちます。
            host = sys.argv[1]
            port = sys.argv[2]
            user_name = sys.argv[3]
            password = sys.argv[4]
            listen_port = sys.argv[5]
            public_port = sys.argv[6]
            
            print('custom host : [%s]' % host);
            print('custom port : [%s]' % port);
            print('custom user_name : [%s]' % user_name);
            print('custom password : ********');
            print('public address : [%s]' % public_address);
            print('channel listen port : [%s]' % listen_port);
            print('channel public listen port : [%s]' % public_port);
            
            connect(user_name, password, 't3://' + host + ':' + port)
            
            edit()
            startEdit()
            ls()
            cd('/')
            cd('Servers')
            cd('myServer')
            create('t3Channel','NetworkAccessPoint')
            cd('NetworkAccessPoints/t3Channel')
            set('Protocol','t3')
            
            set('ListenPort',int(listen_port))
            set('PublicPort',int(public_port))
            
            print('Channel t3Channel added ...')
            activate()
            disconnect()
            

            Summary

            WebLogic ServerはT3プロトコルを使うRMI通信を使用して、WebLogic Serverインスタンス間および他のJavaプログラムとクライアント間を通信します。WebLogic ServerがKubernetesクラスタで動作する場合、RMI通信を行うために考慮すべき特別な事項と構成要件があります。このエントリでは、Kubernetesクラスタの外部からのRMI通信がKubernetesクラスタ内で実行されているWebLogic Serverインスタンスに正常に到達できるように、WebLogic ServerとKubernetesを構成する方法について説明しています。
            EJB、JMS、JTA、WLSTなど、T3 RMIを使用する多くのWebLogic Server機能では、Kubernetesクラスタの内部と外部のクライアントをサポートしています。さらに、マルチノードKubernetesクラスタ内の単一、および複数のWebLogicドメインの両方をサポートします。

            [Java, Security] Understanding why Java signed code needs to be re-signed periodically (even if time-stamped)

            原文はこちら。
            https://blogs.oracle.com/java-platform-group/signed-code-needs-to-be-re-signed

            Javaランタイムには、別のコンピュータからコードを受け入れるためのメカニズムがあります。コードは実行前に安全ではないネットワークを通過する可能性があるため、これらのメカニズムは、プログラムが信頼できるエンティティによって作成され、改ざんされていないことを検証するためのデジタル署名(コード署名)に依存しています。デジタル署名コードにはコード署名証明書が必要です。デフォルトでJavaランタイムが受け入れるのは、信頼できる認証局(CA)が発行した証明書のみです。セキュリティ上の理由から、証明書の発行日から1年間から3年間の限られた期間のみ有効です。
            デジタル署名が有効とみなされるためには、署名自体の有効期限が切れていなくても、コード署名証明書が有効な間に署名をしなければなりません。有効期限が切れた証明書で作成された署名は有効とみなされません。署名がいつ作成されたかを知ることが重要です。残念ながら、ファイルのファイル作成日"プロパティを信頼することはできません。その値が偽造された可能性があるからです。
            コード署名証明書の有効期間中に署名されたことを確認する1つの方法として、署名チェック時に有効な証明書で署名されたコードのみを受け入れる方法がありますが、このアプローチの問題は、たとえコード自体が変更されていなくても、1年に1回、コードを再署名して再配布する必要がある点です。
            証明書の有効期限内に署名が作成されたかどうかを検証する場合、タイムスタンプをつかうとよいでしょう。タイムスタンプの付与には、信頼できるサードパーティであるTSA(Time-Stamping Authority、タイムスタンプ局)が、与えられた署名が所定の日付以前に作成されたことを確認する必要があります。このタイムスタンプは、コード署名証明書が失効する前に署名が行われたという証明として、署名済みコードに追加されます。
            タイムスタンプ自体は、開発者のコード署名証明書ではなく、タイムスタンプの権限証明書を使用した別の電子署名に過ぎませんが、依然として考慮しなければならない同じ規則と独自の有効期限がある点を見落としがちです。理想的には、タイムスタンプ局は、コード署名証明書よりもずっと後に期限が切れる証明書を使用します。
            タイムスタンプサーバーの証明書が失効すると、証明書の有効期限内にタイムスタンプが作成されたことを信頼できなくなってしまいます。コード署名証明書が失効する前に元の署名が作成されたかどうかを確認できなくなります。
            有効期限は、署名が信頼されなくなる理由の1つにすぎません。コード署名やタイムスタンプに関わる証明書は、それらが侵害された場合、もしくは証明書の有効期限が切れる前に、それらの作成に使用されたアルゴリズムがクラックされる場合、取り消される可能性があります。コード署名証明書を無効にするものは、コードの署名に影響します。タイムスタンプ証明書を無効にするものは、タイムスタンプを無効にします。
            タイムスタンプサービスは、遠い将来に有効期限が切れる証明書が常に使用し、長期間有効であると考えられるアルゴリズムと鍵長でのみ署名すると信じられていますが、後方互換性のために中期的には安全でないと思われるアルゴリズムを使用してタイムスタンプを生成することが必要なこともあります。その場合タイムスタンプ局は有効期限の短いタイムスタンプ証明書の利用を選択する可能性があります。
            開発者は、依存している各タイムスタンプサービスの長所や短所、コードの署名が有効でなくなったときの状況を把握し、混乱を避けるための十分な時間をもってコードを再署名して十分に再配布する手順を踏むことが重要です。
            コード署名とタイムスタンプがより低いレベルでどのように機能するか、もっと詳しく知りたい場合は、以下のエントリをご一読ください。
            Understanding Digital Certificates and Code Signing
            http://www.oracle.com/technetwork/java/javase/documentation/digitalcerts-codesigning-4312830.html