ラベル Tuxedo の投稿を表示しています。 すべての投稿を表示
ラベル Tuxedo の投稿を表示しています。 すべての投稿を表示

[Tuxedo] Brand new Oracle Tuxedo 12c

原文はこちら。
https://blogs.oracle.com/Tuxedo/entry/brand_new_oracle_tuxedo_12c

Oracle Tuxedo 12cがもうすぐ出てきますよ。Oracle Tuxedo 12cを2012年7月31日に発表します。是非ローンチイベントに参加頂き、Tuxedo 12cの新機能を知って頂ければと思います。

The #1 C/C++/Cobol Application Server for Conventional and Cloud Environments
新しいOracle Tuxedo 12cは、唯一のオープンかつ堅牢なプラットフォームを提供し、貴社のミッションクリティカルなC/C++/COBOLアプリケーションを開発、展開し、伝統的なデータセンターインフラストラクチャやOracle ExalogicのようなEngineered systems、貴社のエンタープライズクラウド上で実行することができます。新しいOracle Tuxedo Application Runtimes 12cを追加すると、貴社のメインフレームアプリケーションを早期に、廉価かつ低リスクで移行することが出来ます。

TuxedoとTuxedo Application Runtimes 12cで、以下のことが実現できます。
  1. オンプレミスやクラウド環境でのミッションクリティカルなC/C++/COBOLアプリケーションの実行
  2. 最先端の開発ツールや運用ツールを使い、市場への投入時間を短縮し、システムを近代化する時間を短縮
  3. CICS、IMSアプリケーションやバッチアプリケーションをクラウドで利用可能に—メインフレームグレードのRASP(信頼性、可用性、拡張性、性能)をもつプラットフォームで実行
以下のリンクから登録して、ローンチイベントに是非ご参加下さい。お会いできることを楽しみにしています。
Online Launch Event - Introducing Oracle Tuxedo 12c
http://event.on24.com/r.htm?e=495618&s=1&k=E0E681285BF0C2C2248E2BB0B52D6D53

[Tuxedo] Tuxedo Load Balancing

原文はこちら。
https://blogs.oracle.com/Tuxedo/entry/tuxedo_load_balancing

よく頂く質問に、「Tuxedoはどうやって負荷分散するの?」というのがあります。この質問は、特定のサービスを提供しているサーバが捌くリクエストの件数にばらつきがあることを知っているお客様からよく頂きます。
まず、Tuxedoは負荷分散するのではなく、リクエストや負荷の最適化をやっています。言わんとすることは、Tuxedoは特定のサービスを提供する全てのサーバが同じ件数のリクエストを受け取っていることを保証しようとはしておらず、その代わりに最小の時間でリクエストが処理されることを保証しようとしています。シンプルなラウンドロビンの負荷分散を使って特定のサービスのサーバ全てに同じ件数のリクエストを渡すことを保証できるでしょうが、それになんのメリットがあるのでしょうか。
Tuxedoではその代わりに、Queue(SSSQ*やMSSQ**に基づきサーバに対応している場合とサーバに対応していない場合があります)をスキャンして、どのQueueにリクエストを配置すべきかを決定します。
SSSQ : Single Server Single Queue
MSSQ : Multiple Server Single Queue
常に同じ順序でスキャンを実施し、Queueが空の場合はリクエストを即座にそのQueueに配置してリクエストのルーティングを終了します。しかし、全てのQueueが詰まっている場合(リクエストが現在処理中の場合)、TuxedoはWorkリクエスト件数が最小のQueueを選択してリクエストをEnqueueします。ここでworkとは、UBBCONFIGファイルで定義されている「負荷」の値で重み付けされてQueueに入れられた全てのリクエストの合計です。これは軽い負荷であれば、スキャン完了までに空のQueueが見つかることが多いので、最初にスキャンした数個のQueue(サーバ)で全てのリクエストを処理することを意味します。したがって、最初にスキャンしたキュー内のサーバ数個で、ほとんどのリクエストを処理します。最適化されていないように思えますが、実際には、基礎となるオペレーティングシステムおよびハードウェアを十分に活用して、可能な限り最高のパフォーマンスを生成しています。ラウンドロビンスケジューリングを使うと使用可能なすべてのサーバーへリクエストを散らすため、すべてのリクエストがメモリに存在する必要があり、おそらくハードウェアやメモリのキャッシュの方法で多くを共有しないでしょう。Tuxedoのシステムは種々のキャッシュを最大化し、その結果全体のパフォーマンスを最適化します。

このことが、ほとんどのリクエストを数個のサーバで処理している状況を目の当たりにする理由を説明しています。高負荷、つまり、リクエストを処理する全てのサーバに十分な負荷がかかり続けている場合、処理されたリクエスト件数はほぼ均等になることがわかると思います。
次回のエントリでは、クラスタ環境(MP)では負荷分散が少々複雑になるので、クラスタ環境のサーバに適用する方法を取り扱う予定です。

[Tuxedo] Tuxedo is now optimized for Exalogic

Tuxedo 11.1.1.3.0が2011年12月半ばにリリースされたことはご存知でしょうか。既にプレスリリースでご存知の方は、このリリースにはExalogicプラットフォームにおける最適化が含まれていることはご存知かと思います。このエントリがOracle Tuxedo 11.1.1.3.0の機能についてお伝えする最初のエントリです。

Oracle Unveils New Release of Oracle Tuxedo 11g (プレスリリース)
http://www.oracle.com/us/corporate/press/1424296

Exalogicのテクノロジー、特にInfiniband関連のテクノロジー、SDP(Socket Direct Protocol)やRDMA over Infinibandを最大限に活用するためにTuxedoの内部を変更しました。ExalogicやExadata上の他のコンポーネントと通信する際には、すべてのTuxedoコンポーネントは、TCP/ IPの代わりにSDPを使用可能です。 SDPを使用すると、一般的にCPUの利用が少なくてすむため、結果としてアプリケーションに多くCPUの利用時間を割り当てることができます。RDMA over Infinibandを用いると、ノード上のクライアントやサーバプロセスは、BRIDGEプロセスを経由せずに他のノード上のサーバと直接対話できるため、BRIDGEプロセスというボトルネックがなくなること、そして通信のレイテンシが小さくなる効果が見込めます。一例では数ミリ秒になったということです。社内でのベンチマークテストの結果によれば、スループットに劇的な改善が見られました。

また、Tuxedo 11.1.1.3.0の一つのクールな機能として、SPINCOUNTのセルフチューニング機能があります。Tuxedoは、Exalogic上のアプリケーションワークロードを監視し、ワークロードに基づいて動的にSPINCOUNTの値を調整し、CPUサイクルを最適に使用できるようにします。SPINCOUNTはBulletin Boardロックの観点で利用され、SPINCOUNTがTuxedoの運用に影響を与えるため、SPINCOUNTの最適化チューニングが不可欠です。 ExalogicでTuxedo 11.1.1.3.0を使うことで、Tuxedoを設定・構成する際の懸念事項が減るわけですね。

このリリースに含まれる他の機能は以下のようなものがあります。
  • OVM 3.0での動作保証
  • Tuxedo用OVAB (Oracle Virtual Assembly Builder)プラグイン
  • DatabaseをTLOGストアとして利用可能
詳細を知りたい方は是非このブログをチェックして下さいね。

原文はこちら。
http://blogs.oracle.com/Tuxedo/entry/tuxedo_is_now_optimized_for