| Oracle® Fusion Middleware Oracle Coherenceの管理 12c (12.2.1) E69908-02 |
|
 前 |
 次 |
この付録の内容は次のとおりです。
Oracle HotSpot JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
Coherenceでは、JVM当たりのヒープ・サイズを1 - 4GBに保つことをお薦めします。ただし、多数の小さなJVMから得られるパフォーマンスのメリットよりも、少数の大きなJVMから得られる管理の簡易化の方が重要になる一部のアプリケーションには、大きなヒープ・サイズ(最大20GB)が適しています。複数のキャッシュ・サーバーを使用すると、1台のコンピュータでより高い処理能力を実現できます。オラクル社のJVMには4GBを超えるヒープ・サイズが適していますが、GCの一時停止時間を最小限にするために、GCチューニングをお薦めします。チューニングの詳細は、オラクル社のGCチューニング・ガイドを参照してください。また、サイズの固定されたヒープでは通常、GC時間が短縮されるため、そのようなヒープで実行することもお薦めします。詳細は、「JVMのチューニング」を参照してください。
使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、Long値に対して並行アトミック更新が可能となり、同期化は不要です。
サーバー・モードで実行し、安定した並行性の高いバージョンを確実に使用できるようにすることをお薦めします。JVMをサーバー・モードで実行するには、Javaコマンド行に-serverオプションを追加します。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。Sun JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-XX:OnOutOfMemoryError="kill -9 %p"
Windowsの場合:
-XX:OnOutOfMemoryError="taskkill /F /PID %p"
また、OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。Sun JVMでこの機能を有効にするには次のフラグを使用します。
-XX:+HeapDumpOnOutOfMemoryError
IBM JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。IBM JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="kill -9 %pid"
Windowsの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="taskkill /F /PID %pid"
IBM社では、JVMに固定サイズのヒープを割り当てることを推奨していません。ほとんどの場合は、-Xmsにデフォルト値を使用することをお薦めします(つまり、この設定を省略して-Xmxのみを設定します)。詳細は、次のリンクを参照してください。
http://www.ibm.com/developerworks/java/jdk/diagnosis/
OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。IBM JVMでは、デフォルトでOutOfMemoryErrorにヒープ・ダンプが生成されます。さらに構成を行う必要はありません。
LinuxにCoherenceをデプロイする場合は、次の事項に留意してください。
Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。TSCの詳細は、次を参照してください。
https://lwn.net/Articles/209101/
Coherenceおよび基礎となるJVMでは、オペレーティング・システムで使用しているタイムソースを認識しません。システム・ログ(/var/log/dmesg)をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします
kernel: Losing too many ticks! kernel: TSC cannot be used as a timesource. kernel: Possible reasons for this are: kernel: You're running with Speedstep, kernel: You don't have DMA enabled for your hard disk (see hdparm), kernel: Incorrect TSC synchronization on an SMP system (see dmesg). kernel: Falling back to a sane timesource now.
ログ・メッセージによると、これが、CPU使用率の変動(SpeedStep)、DMAの無効化、またはマルチCPUコンピュータに対する誤ったTSCの同期化などに起因して発生していることを示しています。前述のメッセージが存在する場合は、システム管理者に問い合せてその原因を特定し、TSCタイムソースを使用可能にすることをお薦めします。
SolarisにCoherenceをデプロイする場合は、次の事項に留意してください。
Solaris 10上で実行している場合は、パケットの破損およびマルチキャストの切断に関する既知の問題があります。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、後述の両方の問題に対するパッチの適用を強くお薦めします。
Intelギガビット・ネットワーク・インタフェース・カード(NIC)にe1000gドライバを使用するSolaris 10システムに、データ整合性の問題が発生する可能性があります。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000972.1
パッチ118822-21 (SPARC)または118844-21 (x86またはx64)以降がインストールされているSolaris 10システムから送信される場合、IGMP (1)パケットにはIPルーター警告オプションが含まれていません。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000940.1
Solaris 10上で実行している場合は、パケットの破損およびマルチキャスト接続の切断について、前述の「Solaris 10 (x86とSPARC)」の問題を確認してください。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、これら両方の問題に対するパッチの適用を強くお薦めします。
Solaris Mシリーズ・システムには、オンボードNIC (bge)およびPCI接続のNIC (nxge)が含まれます。オンボード・ギガビット・イーサネット・ポートは、ドメインの低帯域幅の管理ネットワーキング接続に使用され、トラフィック需要が大きい高パフォーマンス・クラスタ相互接続負荷用ではありません。Coherenceクラスタ・メンバーは、高帯域幅のクラスタ相互接続には常に専用のPCIe NICを使用する必要があります。
Solaris 11では、トランク・アグリゲーションとデータリンク・マルチパス(DLMP)アグリゲーションの2つのタイプのNICリンク・アグリゲーションがサポートされています。トランク・アグリゲーションではネットワーク・スイッチの使用が必要であり、これはリンク・アグリゲーション・コントロール・プロトコル(LCAP)をサポートしている必要があります。DLMPアグリゲーションでは、少なくとも1つのネットワーク・スイッチの使用が必要です。ただし、DLMPアグリゲーションを使用するときは、トランク・アグリゲーションをLCAPとともに使用するように構成されているスイッチがないことを確認してください。トランク・アグリゲーションからDLMPアグリゲーションに変更する場合、トランク・アグリゲーション用に以前作成したスイッチ構成を削除する必要があります。そのようにできなかった場合、パケットが失われ、ネットワーク帯域幅の利用が低くなる可能性があります。
WindowsにCoherenceをデプロイする場合は、次の事項に留意してください。
初期状態のWindowsは、バックグラウンド・プロセスや重いネットワーク負荷に合せて最適化されているわけではありません。最適化するには、Coherenceインストールのbinディレクトリに含まれているoptimize.regスクリプトを実行します。実行する最適化の詳細は、「オペレーティング・システムのチューニング」を参照してください。
コンピュータでファイアウォールを実行している場合は、複数のコンピュータで構成されるクラスタの形成が難しくなることがあります。これは、次のいずれかを実行すると解決できます。
ファイアウォールの無効化。ただし、これは通常はお薦めしません。
Coherenceを実行するJava実行可能ファイルに対する完全なネットワーク・アクセス権の付与。
Coherenceに対する個別アドレスとポートの開放。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Microsoft Windowsでは、ネットワーク・インタフェース・カード(NIC)がネットワークから取り外されると、そのカードに関連付けられたIPアドレスをオペレーティング・システムが無効にします。この結果、そのIPアドレスにバインドされているソケットがエラー状態になります。これにより、Coherenceノードがクラスタを終了し、NICがネットワークに再接続されるまでエラー状態になります。物理的に停止している間に、複数の連結されたJVMのクラスタ化を保持できるようにすることが望ましい場合は、IPアドレスを無効化しないようにWindowsを構成する必要があります。
このパラメータを調整する手順は次のとおりです。
キーワードの名前にDHCPが含まれていますが、この設定は静的IPアドレスと動的IPアドレスの両方に反映されます。詳細は、「Microsoft Windows TCP/IP Implementation Details」を参照してください。
http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA
OS XにCoherenceをデプロイする場合は、次の事項に留意してください。
OS Xは、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。
z/OSにCoherenceをデプロイする場合は、次の事項に留意してください。
デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、JARファイルからロードされる構成ファイルまたはクラスパスの構成ファイルがASCII形式であることを確認してください。ファイル・システムから直接ロードされた構成ファイルは、システムのネイティブ形式であるEBCDICで格納する必要があります。
状況によっては、IBM zSeriesのz/OS上の同じ論理パーティション(LPAR)内で実行されるCoherenceクラスタ・ノードは、相互に通信できません。(この問題は、zSeriesがLinux上で実行されている場合には発生しません。)
根本的な原因としては、z/OSでは、Coherenceで使用されるMulticastSocketを自動的に割り当てられたポートにバインドする可能性がある一方、Coherenceでは、クラスタ検出が適切に動作するように特定のポートを使用する必要のあることが挙げられます(Coherenceでは、必要なポートの使用のためにjava.net.MulitcastSocketを明示的に初期化しますが、同一のLPAR内で実行されるCoherenceのインスタンスが存在する場合は、その情報がz/OS上で無視されているように見えます。)
この解決策は、z/OS LPAR内ではCoherenceのインスタンスを1つのみ実行することです。複数のインスタンスが必要な場合は、Coherenceの各インスタンスを別々のz/OS LPARで実行する必要があります。または、ウェル・ノウン・アドレス機能を使用することもできます。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
AIXにCoherenceをデプロイする場合は、次の事項に留意してください。
AIX 5.2以降では、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。詳細は、『IBM 32-bit SDK for AIX User Guide』を参照してください。
Oracle Coherenceは、Oracle Fusion Middlewareのサポート・ポリシーに従います。Oracle Fusion Middlewareがサポートする仮想化およびパーティション化のテクノロジについては、次のリンクを参照してください。
http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html
仮想マシンにCoherenceをデプロイする場合は、次の事項に留意してください。
仮想化によりネットワーク・トポロジに別のレイヤーが追加されるため、マルチキャスト・ネットワーキングをサポートするように適切に構成する必要があります。マルチキャスト・ネットワーキングの構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
仮想オペレーティング・システムで実行されるプロセスがギガビット・イーサネットを完全に使用できることはあまりありません。これはCoherenceに特有なことではなく、ネットワーク集中型の仮想アプリケーションの大半に当てはまります。
Cisco社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。
一部のCisco社製スイッチでは、パケットの負荷が重いと、バッファ・スペースが不足し、数秒間の通信停止が頻繁に発生する場合があります。このような通信の停止は、ローカルまたはリモートのGCに起因しない複数ノードでの通信の遅延を指す、一連のCoherenceログ・メッセージにより特定できます。
Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2008-09-15 12:15:47.511, Address=xxx.xxx.x.xx:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512
Cisco 6500シリーズでは、各イーサネット・ポートまたはASICで使用可能なバッファ領域の容量を構成できます。負荷の高いアプリケーションでは、デフォルトのバッファ領域の増大が必要になる場合があります。これを実現するには、次を実行します。
fabric buffer-reserve high
この設定の詳細は、Ciscoのドキュメントを参照してください。
Cisco社のデフォルトのスイッチ構成では、IGMPスヌーピングを使用しているため、スイッチ間でのマルチキャスト・パケットの適切なルーティングがサポートされていません。この問題およびその解決策に関するCiscoのドキュメントを参照してください。
一部のCisco社製スイッチでは、マルチキャスト・グループのメンバーシップの維持が難しいため、既存のマルチキャスト・グループのメンバーが、通知されることなくマルチキャスト・グループから削除されることがあります。これにより、関連付けられたCoherenceノードに部分的な通信切断が発生し、クラスタからの離脱と再参加が強制的に行われます。このような停止はほとんどの場合、部分的な通信上の問題が検出されたことを示す次のCoherenceログ・メッセージによって識別できます。
A potential network configuration problem has been detected. A packet has failed to be delivered (or acknowledged) after 60 seconds, although other packets were acknowledged by the same cluster member (Member(Id=3, Timestamp=Sat Sept 13 12:02:54 EST 2008, Address=192.168.1.101, Port=8088, MachineId=48991)) to this member (Member(Id=1, Timestamp=Sat Sept 13 11:51:11 EST 2008, Address=192.168.1.101, Port=8088, MachineId=49002)) as recently as 5 seconds ago.
この問題を確認するには、実行中のクラスタと同じマルチキャスト・アドレスとポートを使用します。この問題がマルチキャスト・テスト・ノードに影響する場合は、マルチキャスト・テスト・メッセージの受信が突然停止したことが、そのログに記録されます。「マルチキャスト接続テストの実行」を参照してください。
次のテスト・ログはこの問題を示しています。
例A-1 マルチキャストの停止に関するログ
Test Node 192.168.1.100: Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:23 GMT 2008: Received test packet 76 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:23 GMT 2008: Sent packet 85. Sun Sept 14 16:44:23 GMT 2008: Received test packet 85 from self. Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:25 GMT 2008: Received test packet 77 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:25 GMT 2008: Sent packet 86. Sun Sept 14 16:44:25 GMT 2008: Received test packet 86 from self. Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:27 GMT 2008: Received test packet 78 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:27 GMT 2008: Sent packet 87. Sun Sept 14 16:44:27 GMT 2008: Received test packet 87 from self. Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:29 GMT 2008: Sent packet 88. Sun Sept 14 16:44:29 GMT 2008: Received test packet 88 from self. Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:31 GMT 2008: Sent packet 89. Sun Sept 14 16:44:31 GMT 2008: Received test packet 89 from self. Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Test Node 192.168.1.101: Sun Sept 14 16:44:22 GMT 2008: Sent packet 76. Sun Sept 14 16:44:22 GMT 2008: Received test packet 76 from self. Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:22 GMT 2008: Received test packet 85 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:24 GMT 2008: Sent packet 77. Sun Sept 14 16:44:24 GMT 2008: Received test packet 77 from self. Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:24 GMT 2008: Received test packet 86 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:26 GMT 2008: Sent packet 78.Sun Sept 14 16:44:26 GMT 2008: Received test packet 78 from self. Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:26 GMT 2008: Received test packet 87 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:28 GMT 2008: Sent packet 79. Sun Sept 14 16:44:28 GMT 2008: Received test packet 79 from self. Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:28 GMT 2008: Received test packet 88 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:30 GMT 2008: Sent packet 80. Sun Sept 14 16:44:30 GMT 2008: Received test packet 80 from self. Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:30 GMT 2008: Received test packet 89 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:32 GMT 2008: Sent packet 81.Sun Sept 14 16:44:32 GMT 2008: Received test packet 81 from self. Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:32 GMT 2008: Received test packet 90 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:34 GMT 2008: Sent packet 82.
16:44:27に、最初のテスト・ノードで、他のコンピュータからのマルチキャスト・パケットの受信が停止しました。オペレーティング・システムにより、同一コンピュータ上のその他のプロセスからのマルチキャスト・トラフィックは、引き続き適切に転送されましたが、2番目のテスト・ノードからのテスト・パケット(79以降)は受信されませんでした。また、テスト・パケットおよび最初のノードによって生成されたクラスタのマルチキャスト・トラフィックは両方とも、引き続き2番目のノードに配信されました。これは、最初のノードがマルチキャスト・グループから通知なく削除されたことを示します。
このマルチキャストに関する問題が発生した場合は、Cisco社のテクニカル・サポートに連絡してください。または、ウェル・ノウン・アドレス機能を使用して、ユニキャストのみの構成に変更することも検討してください。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Foundry社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。
Foundry社製スイッチでは、マルチキャスト・トラフィックの処理が困難です。Foundry社製スイッチを使用してデプロイするときには、Coherenceクラスタに属するすべてのコンピュータがマルチキャスト通信できることを確認してください。「マルチキャスト接続テストの実行」を参照してください。
マルチキャストに関する問題が発生した場合は、well-known-addresses機能を使用してユニキャストのみの構成に変更することも検討してください。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
IBM BladeCenterにCoherenceをデプロイする場合は、次の事項に留意してください。
BladeCenterへの通常のデプロイには、それぞれ管理用とクラスタ・トラフィック用の2つのNICを備えたブレードが使用されます。デフォルトでは、BladeCenterのブレードに割り当てられるMACアドレスには均一性があるため、通常最初のNICには偶数のMACアドレスが、2番目のNICには奇数のMACアドレスが割り当てられます。また、中央のスイッチへのBladeCenterのアップリンクにも偶数個のチャンネルがある場合は、レイヤー2 (MACベース)のロード・バランシングにより、使用可能なアップリンクの全帯域幅が1セットのNICで消費されないように調整されます。すべてのNICは、偶数個または奇数個のチャンネルのどちらかにバインドされるためです。この問題は、スイッチではMACアドレスが基本的にランダムであるという前提によるものですが、BladeCenterには当てはまりません。この状況の対応策は次のとおりです。
レイヤー3 (IPベース)のロード・バランシングを使用します(IPアドレスが同じ偶数/奇数パターンを踏襲しない場合)。
この設定は、クラスタ・トラフィックの伝送を行うすべてのスイッチに適用する必要があります。
代替コンピュータの1番目と2番目のNIC間でMACアドレスを入れ替えることにより、MACアドレスの割当てをランダムにします。
Linuxでは、ifconfigコマンドを使用してNICのMACアドレスを変更できます。
その他のオペレーティング・システムでも、カスタム・ツールを使用して同様のタスクを実行できる場合があります。
