各ファイルについては，下記のフォーマット（書式）で記述すること．

各ファイル共通

• 改行コードは LF を使用すること
• マルチバイト文字列が含まれるファイルは，文字コードセットとして UTF-8 を使用すること
• 一行の文字数は 80 字以内とすること
• ホワイトスペースは半角スペースを使用すること（全角スペースは使用禁止とする）
• インデントは半角ホワイトスペース 4 個を使用すること
• コメントは // 形式を使用すること
  • 複数行にわたるコメントについても，各行の先頭に // を挿入しコメントとすること
• ファイル冒頭に適用ライセンスに沿ったライセンス条文を挿入すること
  • LGPLv3 原文
  • LGPLv3 日本語訳

ヘッダファイル（*.h）

• 宣言が重複しないよう，マクロを定義すること
  • マクロ名は，下記のルールに従って命名すること
    • プレフィックスにアンダースコアを付加
    • ファイル名をすべて大文字に変換
    • ドットはアンダースコアに変換
    • サフィックスにアンダースコアを付加
  • #endif ディレクティブを記述する行のコメントとして，マクロ名を記述すること．

例： scheduler_rr.h の場合

#ifndef _SCHEDULER_RR_H_
#define _SCHEDULER_RR_H_
....
#endif // _SCHEDULER_RR_H_

• ヘッダファイル内で #include を使用しないこと
  • ソースファイル内で，インクルード順序を考慮すること
• クラスを定義するヘッダファイルの場合は，ひとつのファイルにひとつのクラスを記述すること
  • ただし，密接に関連するクラス（特定のクラスに対する例外を処理するクラスなど）は同じファイルに記述することを許容する

ソースファイル（*.c，*.cpp など）

• マジックナンバを使用しないこと
  • 定数を使用する場合は，マクロとして定義すること
• #include によるインクルードは，先頭部分でのみ行うこと
  • インクルードの順序は，下記の順とし，各括りの中ではアルファベット順に記述する
    1. config.h など，プロジェクト独自の定数が定義されているファイル
    2. C 向け標準ヘッダファイル
    3. C++ 向け標準ヘッダファイル
    4. その他外部ライブラリ用ヘッダファイル
    5. プロジェクト固有ヘッダファイル
• NULL 判定を行う場合は，0 ではなく NULL を使用すること
• 配列や構造体のサイズを sizeof キーワードによって取得する場合は，対象の変数ではなく，型を指定すること

  int foo(...)
  {
      struct data_structure data;
      int data_size = 0;
  
      data_size = sizeof (data); // bad
      data_size = sizeof (struct data_structure); // good
      ....
  }
  

• goto を適切に使用し，コードの重複を避けること

  #define USER_NAME_LENGTH 64
  #define PASSWORD_LENGTH  64
  int foo(...)
  {
      int error_code  = 0;
      char *user_name = NULL;
      char *password  = NULL;
  
      user_name = (char *) malloc(sizeof (char) * USER_NAME_LENGTH);
  
      if (user_name == NULL) {
          error_code = -1;
          goto user_name_initialization_failed;
      }
  
      password = (char *) malloc(sizeof (char) * PASSWORD_LENGTH);
  
      if (password == NULL) {
          error_code = -1;
          goto password_initialization_failed;
      }
  
      // some operation
  
      free(password);
  
  password_initialization_failed:
      free(user_name);
  
  user_name_initialization_failed:
      // nothing to free
      return error_code;
  }
  

  Pour vous inscrire maintiennent numéro, vous aurez pu votre compte driver (utile à votre portabilité du numéro) numéro rio. Vous obtiendrez pouvez obtenir pour aucun coût par entrer en contact avec la voix expression du serveur ou du service à la clientèle votre propre vieille fournisseur numero rio bouygues . Vous ne mai get un SMS avec vos . Avec votre rio orange, alors vous serez en mesure de vous abonner à l' offre de de son à propos citrons .

OLS2009で発表されているように、MultiQueueやRPS、そしてFDIRのようにネットワークを取り囲む環境は今ちょうど新しい機能が次々と導入されつつある。
それは、CPUのシングルスレッド性能の向上が止まったのを回避するための施策であるが、これらの対応はkernelにとどまることなく、アプリケーション側からも対応しなければ速度を引き出すことは出来ない。
ここでは、UltraMonkey-L7のMultiThreadModelを考慮して検証を行う

MultiQueueを利用した時の起動シーケンスと必要データ

起動時にMultiQueueを使用してるときほしい情報

情報名	概要
MQのON/OFF	MQ対応のNICでもON/OFFが出来るため
FlowDirectorのON/OFF	将来的にFlowDirectorがON固定になるかもしれないが、使えない環境ではプログラムが変更になる
Queueの振り分け種別	接続を振り分けるときにIP/PORTやMACアドレス等色々な種類で振り分けるはず。振り分け種類は起動時に確定するはず
Queue総数	Queue:ThreadPoolの比率で作成するため、全thread数はQueueの数 x ThreadPool一つあたりの数になる
各Queueに紐づけられているCPU	ThreadPoolはCPUごとに(sched_set_affinityを利用して)くくりつけるため、最初に必要

RPSを使用したときの起動シーケンスと必要データ

起動時にFlowDirectorを利用している時ほしい情報

情報名	概要
FlowDirectorのON/OFF	kernel機能であるFlowDirectorが有効かどうか
使用するCPUMask	現状sysfsで提供されている(未確認)
CPU振り分け種別	RPSで振り分けるキーはIP/PORT?(要調査)

HTTPサーバをMultiQueue + FlowDirector=OFFで中継する場合

FlowDirector=OFFの場合は送信から始まるRealServerSideThreadを考慮する必要がある。
上記シーケンスを解説すると、

1. LisningThreadがClientからの接続をacceptしたときに、以降Clientとの通信を行うThreadが動くCPUの情報を得る。
2. LisningThreadは取得したCPUに結びついているThreadPoolよりThreadを一つ取り出しClientSideThreadとしてFDをコピーする(そして、LisningThreadは再びLisnに戻る)
3. ClientSideThreadはl7vsdのプロトコルモジュール処理を行い、RealServerのアドレスを確定する。
4. 確定したRealServerのアドレスから使用するQueueにくくりついたCPU情報を取得する。
5. 取得したCPUに結びついているThreadPoolよりThreadを一つ取り出し、RealServerSideThreadとしてアドレス情報をコピーする。
6. RealServerSideThreadはアドレス情報よりRealServerに対してConnectを行う

と、なりkernelより取得すべき情報は

情報名	概要
acceptしたFDからのCPU情報	今現在使用しているコネクションのFDが使用しているqueueにくくりついたCPU番号
ADDRINFOからのCPU情報	振り分け種類がIP/PORTの時のみ、ADDRINFOにて使用するqueueにくくりついたCPU番号

これらの情報は一接続ごとに問い合わせを行う必要があるため、sysfsでは速度的にコストがかかりすぎる懸念があり、ioctlもしくは、専用APIでのアクセスが望ましい。
ちなみにFlowDirectorがOnの場合には送信時に使ったQueueが受信時にも使われるため、プログラムとしてはラウンドロビン的にThreadPoolからRealServerThreadをActiveにすればよい。

HTTPサーバをRPS+MultiQueueで中継する場合

RPSを使用しているときのシーケンスは

1. LisningThreadがClientからの接続をacceptしたときに、以降Clientとの通信を行うThreadが動くCPUの情報を得る。
2. LisningThreadは取得したCPUに結びついているThreadPoolよりThreadを一つ取り出しClientSideThreadとしてFDをコピーする(そして、LisningThreadは再びLisnに戻る)
3. 送信処理のCPUMaskは起動時得られる?

と、なりkernelより取得すべき情報は

情報名	概要
acceptしたFDからのCPU情報	今現在使用しているコネクションのFDがのパケット処理を行うCPU番号
送信するNICに割り込みを上げているCPU	動的に変化するわけではないから、.confで間に合う?

RPSとMQの同時使用の場合は考察すべき部分がもう少し増えます。
受信CPU選択時にRPSのほうが有効になる?か、要調査。 Pour participer garder le numéro, vous aurez Bill opérateur d'identification (obligatoire à votre portabilité du numéro) numero rio. Vous obtiendrez pouvez obtenir pour totalement gratuit par appelant mots du serveur ou du service à la clientèle votre propre fournisseur rio bouygues . Vous ne obtenir un SMS utilisant votre. Avec votre actuelle numero rio orange, alors vous êtes capable d' à l' offre de votre à propos rouge.

会談目的
LinuxのNetworkの開発者であるDavid S.Miller様とMultiQueueのメンテナであるHerbert Xu様とFernando Luis Vázquez Cao様のご尽力により会談が実現しました。
この会談の意義は、現在kernelで進行中のMultiQueueの実装及びIFについて、l7vsd側からどのような方式が望ましいのか、そしてkernel側としてはユーザー空間側のプログラムがどのような挙動を望んでいるのかの意識をすりあわせることにより、双方にとって最適なMultiQueueのKernel実装を導き出すことを目的にしています。

現状のLinuxでのMultiQueueに対する2つの件
今回確定的な件は以下の二つ。

• 「現状のMQ実装でNICを2枚利用した場合の不具合」 proxyやロードバランサのようにNICが2枚ある場合に二枚目のNICで送信する場合にskb_hashを呼び出すことでCPUの使用がずれる件
• 「ラウンドロビン式のQueue使用方法」新規に受け付けた接続がIPとPORTのhash値を計算して使用するQueueを選択する既存の方式に対して、ラウンドロビンで接続順にQueueを選択し、CPU使用率の分散化を図るハードウェア拡張

この二つのことに関して、以下に説明させていただきます。

■現状のMQ実装でNICを2枚利用した場合の不具合

現状での問題が発生する図です。
NICが二枚ある場合、DirectedAcceptの機能により上記にあるように受け付けたQueueが割り振られているCPUのThreadのacceptが反応するため、スケジューリングコストは最小限であり、他のCPU上のメモリを参照もしないため、コストは最小限で抑えられます。
しかしThread内部で別のNICから送信する場合、kernelは新規接続になるためにskb_hash()関数(kernelのnetwork coreに存在する関数)を呼び出し、使用するQueueを選択します。
この場合、Threadが所属するCPUと同じQueueが使用される保証は全くなく、逆に別CPUで実行される確率の方が高いため、CPUをまたいだ処理になるためスケジューリングコストが増大し、かつ別ノードのメモリを参照するため性能低下が激しくなります。

これはDavid.S-Millerさんも納得されており、Fernandoさんがパッチを投稿すると云う段取りになりました。
その改善案が次の図にようになります。

単純にskb_hash()を呼び出さない実装ではなく、接続を開始したthreadが所属するCPUを判断して使用するQueueを選択します。
この修正をすることで、今までNICを2枚使用した場合に2枚目からの送信時にタスクスケジューラが送信に使用したQueueと同じCPUにThreadを割り振ろうとしCPUを移動させて、次に1枚目のNICよりデータを受信するときに再びタスクスケジューラが元のCPUへとThreadを移動させようとThreadの帰属CPUが頻繁に変更されるような状況を作り出していた不具合が無くなります。

■ラウンドロビン式のQueue使用方法
現状のNICにおいて、接続要求を行うコネクションがどのQueueを使用するか、そのアルゴリズムはデフォルトでIP/PORTよりhashを計算して使用するQueueを決定しています。

他にもMACアドレスでQueueを確定する方法などがありますがこれらの方式で問題となるのがhashを求める段階で偏りが発生する可能性があるという事ですね。
特に、MACアドレスでQueueを選択する場合、L3スイッチに直接接続されている場合などはたった一つのQueueしか使用出来ません。
複数のCPUを使って処理効率を上げようというアプローチが有効に機能しないことが発生します。

某商用のソフトウェアはハードウェアラウンドロビン機能を使ってこの状況を回避しています。
接続順と云う要素からqueueの使用場所を決めるというアプローチで全てのqueueが均等に使えるように工夫されています。

このハードウェア機能を利用することにより効率的にCPUを利用できるようになります。

Ultramonkey-L7のプログラム構成についての考察
これらFlowDirectorやDirectedAcceptなどを効率よく利用できるようなソフトウェア構成を考察する必要があります。
DirectedAccept、FlowDirectorなどを考慮したソフトウェア構成を考察すると次のようになります。

DirectedAcceptはacceptの所属するthreadのqueueを利用しacceptに反応を上げる作りですから、queueの数だけacceptが並列に動ければもっとも効率的に処理が可能になります。
もちろん、threadの作成と消滅にはコストがかかりますので、使用するthreadは予め作成し、休止状態にしてpoolingしておきます。
つまりこの構成で一番重要なのはqueue1つにつき1つのacceptを用意すると云うことです。この1つのCPUについての構造を以下に示しましょう。

図のような構造がCPUごとに用意されると思ってください。もちろん、VirtualServiceごとにLisningSocketがありますから、l7vsd全体で見た場合にはqueue:acceptor = 1 : n になります。
この構造で一番の重要な部分はacceptor threadがqueueにデータ入るのを監視するためにnon-blockingで読み出しを行うと言う部分でしょう。David様に確認したところこの構造が一番速いと云うことなので速度を考察した場合にはnon-blockingで呼び出しを行うことが最優先かと思います。
次にacceptして新しいsocketが取得出来たところで、accept threadはsession threadにsocket情報と含めて引き継ぎ、以降の処理はsession threadが処理を引き継ぎます。
ここで大事なのは、処理のスタートはaccept threadが必ず起点になってthread poolから休眠中のthreadを起こしてきますが、処理が終わるとき、コネクションが切断されたりするときにはthreadは自分で後処理をしてthread poolに戻る必要があると云うことです。
また、thread poolにはスタック的にthreadをため込む必要があります。
これはthread自身がメモリを必要とし、メモリアクセスは局所性を持たすべく(そのためにキャッシュメモリが存在する)なるべく直近に使ったthreadを使い回すコードを意識する必要がある為です。

作りとしてはacceptをCPUにくくりつけて構成するという部分が一番のキモでしょうか。これに付随して対応するNICや、どのように各情報を引き出してくるかはkernelをwatchする必要があります。 Pour participer maintenir votre numéro, vous aurez peuvent avoir compte driver (utile à votre portabilité mobile) rio bouygues. Vous obtiendrez pouvez obtenir pour totalement gratuit par téléphonant expression du serveur ou du service à la clientèle satisfaction client partir de votre fournisseur de services code rio bouygues . Vous ne mai recevez immédiatement un SMS avec votre . Avec votre propre code rio orange, alors vous pouvez vers le offre de de son à propos fruits .

ネーミングルール

クラス

大文字で始まる名詞をつける。内容の省略は行わないこと。アンダースコアでの連結も行わないこと。

 class AccountManager : public ManagerBase{
   ...
 }

 class ACCOUNTManager : public ManagerBase{
   ...
 }

 class Account_manager : public ManagerBase{
  ...
 }

 class AccountManage : public ManagerBase{
  ...
 }

 interface NameOfInterface{
  ...
 }
 class NameOfInterfaceImpl{
  ...
 }

  class AbstractVivaHoge{
  ...
  }

関数

  public void getInstance(){
  ...
  }

定数

  static final int DEFAULT_ACCESS_LIMIT = 15;

インスタンス

  class Sample {
    ...
  }
  Sample sample;
  sample.setArg( ... );

配列

 String[255] nameArray;

パッケージ名

javadoc

JavaDocサンプル

/**
 * Outline of Class(クラス概要)
 * ピリオド(.)または句点(。)で終わるところまでが、クラス一覧の概要に説明されるところであり、
 * ピリオド以降は説明の概要には含まれず、クラスの説明に含まれる。
 * このように、JavadocにはHTMLタグを使用することができる。
 * </pre>
 * @author tanuma
 * @author nakai
 * @version 1.0
 * @since 1.0
 */
public class SampleDoc{

  /**
   * @serial 直列化可能データの説明
   */
  private int x;

  /**
   * Validates a chess move.
   * @author kubota
   * @param theFromFile File of piece being moved
   * @param theFromRank Rank of piece being moved
   * @param theToFile   File of destination square
   * @param theToRank   Rank of destination square
   * @return true if a valid chess move or false if invalid
   */
  boolean isValidMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
  {
     ...
  }

  /**
   * Outline of method(関数説明)
   * @param int Outline(引数)
   * @throws SomeException 例外の説明
   * @throws Exception 例外の説明
   * @return String型の値
   * @see "関連"
   */
  String add( int inint ) throws SomeException, Exception {
    
  }
}

そのほか

---

Debugで出力するLogは基本的に以下の情報を出力する。

• コンストラクタ時のメッセージ
• 関数の入通知と引数のダンプ
• 関数の出通知と返値のダンプ
• servletの場合には受け取ったPOSTデータの値

　　　　以下必要な情報は随時追加

---

---

example. jsp

<%@ page language="java" contentType="text/html; charset=ASCII" %>
<%@ page import="org.apache.log4j*" %>
<%@ page import="org.ultramonkey.l7.model.*" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html"; charset=ASCII">
<title>sample</title>
<body>
<%
  Logger logger = Logger.getLogger( LogCategorySet.JSPCategory );
  if( logger.isDebugEnable() ){
    logger.debug( "sample.jsp start" );
  }
  SampleClass sampleClass = SampleClass.getInstance();
  if( null == sampleClass ){
    logger.error( "SampleClass.getInstance() is NULL!" );
  }
%>

hello world!
<%
  if( logger.isDebugEnable() ){
    logger.debug( "sample.jsp exit" );
  }
%>
</body>
</html>

example class

package org.ultramonkey.l7;
import org.apache.log4j.*;

public class Sample{
  Logger logger = null;
  public Sample(){
    logger = Logger.getInstance( LogCategorySet.SampleCategory );
    if( logger.isDebugEnable() ){
      logger.debug( "class Sample created." );
    }
  }
  public String foo(Sample sample, String string) throws Exception {
    // debug log (in method)
    if( logger.isDebugEnable() ){
      StringBuffer buf = new StringBuffer();
      buf.append("Sample::foo(Sample sample, String string) throws Exception in ");
      buf.append("sample=" + sample + ", ");
      buf.append("string=" + string);
      logger.debug(buf.toString());
    }

    if( null != sample ){
      logger.error( "in sample value is null. check configure" );
    }

    // debug log (out method)
    if( logger.isDebugEnable() ){
      StringBuffer buf = new StringBuffer();
      buf.append("Sample::foo(Sample sample, String string) throws Exception out ");
      buf.append("return=" + sample.toString + string);
      logger.debug(buf.toString());
    }

    return sample.toString + string;
  }
}

UltraMonkey-L7 の設定管理を行う CUI コマンド l7vsadm に関する説明を記載しています。

UltraMonkey-L7 からSNMPで取得できる情報

UltraMonkey-L7 が発出するTRAP情報

UltraMonkey-L7 のSNMP機能に関する説明を記載しています。

概要

UltraMonkey-L7 の SNMP機能は は、NetSNMPを利用することで、SNMPマネージャから UltraMonkey-L7 のステータス・設定状況の確認、およびTRAPの送信などが行えます。

拡張企業番号

UltraMonkey-L7の拡張企業番号は 32132 です。

拡張MIBの定義

SNMPエージェント(マスターエージェント)

• NetSNMPを利用する

SNMPが利用可能なUM-L7のバージョン

• UltraMonkey-L7 v3.0.x 以降

プロジェクトについて

• プロジェクトメンバと役割

概念

構成

• UltraMonkey-L7 本体プロセス (l7vsd)
• UltraMonkey-L7 設定管理コマンド (l7vsadm)
• UltraMonkey-L7 監視プロセス (l7directord)
• UltraMonkey-L7 設定管理 GUI

インストール

• UltraMonkey-L7 動作に必要な環境
• UltraMonkey-L7 構築に必要なライブラリ
• UltraMonkey-L7 GUI 動作に必要なライブラリ

設定

• l7directord.cf
• l7vs.cf
• Hartbeat2
• GUIApplication

運用

• シングルモードで通常セッションで行う場合
• シングルモードでSSLセッションをUltraMonley-L7と同じ筐体でDecodeする場合
• クラスタ構成を組む場合
• UltraMonkey-L4との同居
• SNMP
• MIB情報
• TRAP
• GUIApplication

マニュアル類

• UM-L7関連公式マニュアル類（インストールマニュアル、管理マニュアル、HB設定等）

用語集

FAQ

LINK

ノウハウ置き場

• 性能改善関連ノウハウ

開発者向

次期リリースに向けた機能検討

• UltraMonkey-L7-2.x-sachiel に取り込む機能
• UltraMonkey-L7-3.x-shamshel に取り込む機能
• UltraMonkey-L7-2.1.1-0 & sslproxy-1.0.1-0 リリース
• UltraMonkey-L7-2.1.2-0 リリース
• sslproxy-1.0.1-1 リリース

codeing規約

• フロントページ
• C/C++言語
• java言語

Logging指針

configure指針

UltraMonkey L7(v3.0.2) を RHEL6.0 で動かし，最大性能を計測すると，RHEL5.5 で動かした UltraMonkey L7(v2.3.0) よりも性能が上がらない

• 原因
  • その 1： 1 CPU コアに処理が偏っていたため
  • その 2： 不要なカーネルモジュール（nf_conntrack）が CPU を消費していたため
  • その 3： RHEL6 のプロセススケジューラ（CFS）が UltraMonkey L7 v3 と相性の悪いスケジュールポリシーだったため

• 対策
  • その 1： NIC の割り込みが CPU 0 に偏っていたため，効率的に処理するために RHEL6 のスケジューラがスレッドを CPU 0 に偏らせていた
    • NIC の割り込みを各 CPU コアに分散(multqueue)させて，スレッドを各 CPU コアに分散させた
      • スレッドは各 CPU コアに分散したものの，UltraMonkey の性能は向上せず
  • その 2： nf_conntrack モジュールをカーネルからアンロード
    • UltraMonkey の性能が 6％ ほどアップ
  • その 3： CFS は sleep していたスレッドが起床すると，それまで動いていたスレッドをとめて sleep から起床したスレッドに動作を切り替える
    • 大量のスレッドが短い間隔で sleep と起床を繰り返す UltraMonkey v3 では，オーバーヘッド負荷が大きすぎる
      • スレッドが起床してもすぐには動作が切り替わらないようにスケジューラのパラメータを調整
        • UltraMoneky の性能がさらに 24％ アップし，対策 2 とあわせて 30％ ほどアップ．RHEL5.5 上の v2 の性能を越え，限界性能クライアント数が 67,000 に達する

NUMA構成図

複数のCPUで同一のメモリ空間を持つシステムのうち、CPUとメモリアクセスに差があるシステムを指す。
一般的にCPUコアの数が多くなるとNUMA構成をとりやすい。
ItaniumやOpteron、Core7i等がNUMA構成となる。
Core2DuoはNUMA構成とはならない。
NUMAのメリットはプロセッサに近いメモリアクセスが高速に行えると言う点。
CPUコアとメモリをセットにし、それらをインターコネクトで接続し、全コアでメモリ空間は共有する。
ただし、他のCPUが持つメモリへのアクセスはそのメモリを持つCPUを経由してアクセスするために遅くなる。
ソフトウェアはメモリ位置によりアクセス速度が異なることを意識する必要がある

一般的なルール

UltraMonkey-L7 に関連するソースコード一式については，メンテナンス性維持のため本規約に従い記述することとする．

下記以外の記法や命名規則などは C++ Coding Standard に従う．

目次

• ディレクトリ構成
• ファイルフォーマット
• 名前付けに関する規則
  • 識別子ごとの命名規則

各識別子ごとの名前付け規約

各識別子の名称は，下記に示すとおりの規則に従って付与すること．

名前空間

記法

すべて小文字で l7vs とする．（固定）

命名規則

l7vs

例外なく，l7vs 名前空間の中に記述する．

サンプル

例）

namespace l7vs {
  class logger {
    public:
      logger();
      ~logger();
  };
};

クラス

記法

すべて小文字で記述する．
単語と単語の接続には，アンダースコアを使用する．

命名規則

簡略な名称を付与し，単語を省略せずに記述する．

サンプル

例）ログ出力用クラス

class logger {
  public:
    logger();
    ~logger();
};

logger module_logger;

列挙型/列挙子

記法

すべて小文字で記述する．
単語と単語の接続には，アンダースコアを使用する．

命名規則

簡略な名称を付与し，単語を省略せずに記述する．

サンプル

例）ログレベル

enum log_level {
  fatal,
  error,
  warning,
  information,
  debug
};

関数

記法

すべて小文字で記述する．
単語と単語の接続には，アンダースコアを使用する．

命名規則

[Verb][Target] とし，単語を省略せずに記述する．

サンプル

int run_thread()
{
...
}

int send_signal()
{
...
}

変数

記法

すべて小文字で記述する．
単語と単語の接続には，アンダースコアを使用する．

命名規則

簡略な名称を付与し，単語を省略せずに記述する．

ただし，ループ用変数などは n，i，j などを使用してもよい．

サンプル

int run_thread()
{
  int thread_number;
  ...

  for (int i; i < thread_number; i++) {
    ....
  }
}

Outline

1. 一般的な名前付け規約
   1. 使用する文字
   2. 複合語の扱い
   3. 省略形の禁止
   4. ハンガリー記法の禁止

一般的な名前付け規約

すべての名前空間，クラス，構造体，パラメタなどは，後述の規則に従って付与すること．

使用する文字

define で定義されたマクロ以外は，すべて小文字英数，数字，アンダースコアで記述すること．

複合語の扱い

複合語（たとえば password，scoreboard など，一般的な辞書に掲載されているもの）は単一の単語として扱う．

注意: filename，username などは複合語ではない．user_name，file_name などと記すこと．

例）

  // Bad -- 「score_board」というキーワードでないと検索できない．
  // このソースでは「score」と「board」は別単語として扱われていることを知っておく必要がある．

  std::map<int, char*> score_board;
  int score_board_index;

  // Nice -- 「socreboard」というキーワードで検索できる．
  // 一般的な英語の知識があれば良い．
  
  std::map<int, char*> scoreboard;
  int scoreboard_index;

省略形の禁止

省略された単語は本来の意味を理解する妨げとなるため，必ず全体を記述すること．

例）

  // Bad -- wd が何を示すか不明瞭である．

  std::string passwd;

  // Nice -- パスワードであることが明確である．  

  std::string password; // Nice

ハンガリー記法の禁止

ハンガリー記法は命名時に型を拘束するため，これを禁止する．

例）

  // Bad -- sz は，String terminated by Zero の略．
  //「NULL ターミネートされたキーワードを示す文字列である」ことを永続的に拘束する．

  char* szKeyword = "The Keyword"; 

  // Nice -- 「キーワードである」という変数の意味のみを拘束する．
  // 後に独自のクラスに置き換える場合も，変数名に影響は少ない．

  char* keyword = "The Keyword";

UltraMonkey-L7

./
  doc/
    conf/
    heartbeat-ra/
    man/
  l7directord
    t/
      lib/
  l7vsd
    include/
    init.d/
    module/
      protocol/
      schedule/
    src/

v2 からの変更点

• l7vsd と l7directord のふたつにディレクトリを分離
  • 設定ファイルのサンプル，man ページなどは一元管理

• ./conf ディレクトリを廃止し，doc 配下に配置

• ./man ディレクトリを廃止し，doc 配下に配置

• logger ディレクトリと parameter ディレクトリは廃止
  • src 配下へ移動
  • C++ へ全面移行するため，デマングル用インタフェイスは不要との考え

version 1.40
boostライブラリをversion noに関係ないsharedlibの命名規則を用いて/usr/includeと/usr/lib64にinstallする方法。

# ./bootstrap.sh
# ./bjam --prefix=/usr --libdir=/usr/lib64 --layout=system link=shared \
  threading=multi variant=release stage install

3.x系では今現在のepollでのシングルスレッド構造を見直し、全面MultiThreadで構築を模索する。
また、MultiThread化に伴い昨今のLinuxでのネットワークの取り組みになるべくあわせた方式を考慮する。

• JapanLinuxSimposiumでのDavid.S-Millerとの会談について(New!)
• kernelのMulti accept実装(New!)
• プログラムモデル
• LinuxKernelのNetworkModelへの対応
• Makeing boost C++ lib Tips

語彙説明

• NUMA
• NAPI
• 82599EB)
• MultiQueue
• Receive packet Steering)
• Side Scaling)
• Flow Dorector)

FlowDirectorがユーザー空間へと出す機能としてMulti Acceptが検討されている。
これは、我々がacceptの後で取得したFDがどのCPUを利用しているか?と言う、着眼点だったのだがacceptするFDを複数のthreadで同時にacceptを行うことで、kernrl内部にはacceptしているthreadのリストが出来るため、接続するQueueが使用するCPUとリストのCPUを付き合わせ、マッチするCPU上で動いているThreadのacceptに反応を起こさせる。
こうすることで、kernelはacceptの段階でどのCPUを利用しているThreadかという情報は取得できるので、どのthreadのacceptを呼ぶのかを確定出来るはず。
またこれを使うとthread poolの実装そのものになるかも?

スレッドモデル UltraMonkey-L7(以下、l7vsd)が取り得るべきthread方式を以下に示す。

スレッド方式名	メリット	デメリット
woker方式	既存の構造の延長でのマルチスレッドになる	MQの構造などに対応できない
updown方式	upstream側とdownstream側でthreadを分けることによりブロックせず動ける	MQの構造に半分対応出来ない、工数が多い
side方式	ClientSideとRealServerSideでthreadを分けることによりMQの構造に対応出来る	工数が多い

これらの方式が存在するが、現状のLinuxKernelの方針からSide方式を検討する。 Side方式によるThreadの種類は以下の物がある。

スレッド種類	概要
Lisingスレッド	VirtualService一つにつき一つ作られる。acceptしたらClientThreadに処理を引き渡す。
ClientSideスレッド	Clientからのデータ受信、データ送信を行うthread
RealServerSideスレッド	RealServerからのデータ受信、データ送信を行うthread

上記スレッドが主要な種類になり、以下のような配置になる(他にもメインスレッドとバーチャルサービススレッドが考えられるがこれらはグルーピングの単位のため、ここでは考察しない。)
この図ではまず、Client側NICにClintからの接続要求(赤い破線)がくるところから始まる。
MultiQueueを使っていたとしても全てのCPUでLisningSocketをbindしているわけにはいかないので、この部分は他のCPUからの割り込みがLisingScoketをbindしているCPUに入ってくることになる。
その後、acceptした時に、l7vsdはconnectionがどのCPUを使っているのかを判断し、図ではCPU1に割当たっているClientSideThreadに処理を引き継ぐ。
このClientSideThreadはCPUごとにpoolingする必要があり(threaqdのcreateは非常に重いため)、LisingThreadはconnectした通信がどのCPUを使っているのかを判断し、該当のCPUに結びついているThreadPoolからThreadを引き出す。
図にあるようにLisningしているThreadは一つでかつ、シリアライズされる部分。
acceptしたときに接続が使用しているCPUにくくりつけられたThreadPool(ThreadPoolの中にあるThreadは全てcpu affinityでCPUに結びついています)よりThreadを引き出して処理を引き出したThreadに委任する。
LisningThreadの仕事はここまでで、再びLisningThreadは次のaccept処理のloopに入る。
ClientSideSocketはRealServerSideThreadを該当のThreadPoolより引き出してActiveにする。
ちなみにThreadがPoolに戻るタイミングは、自分と対向側のコネクションが切断された場合であり、それぞれのthreadがばらばらに(どのタイミングになるかは予測できない)に戻る。
タイミングによってはThreadPoolへ集中して戻される事象の発生が予測されるため、ThreadPoolのプログラミングは非常に考慮する必要がある。

NAPI動作図

kernel2.6より導入されたネットワークフレームワーク。(詳細は待て!)

UltraMonkey-L4

Layer-4相当でのロードバランシングを行う負荷分散プログラム、UltraMonkey-L4のプロジェクトページ。

Vanessa libraries

UltraMonkey-L7で使用しているライブラリ群

GTK+ The GIMP Toolkid

UltraMokey-L7で使用しているGLib2.xのプロジェクトページ。日本語のリファレンスマニュアルはgnomeユーザーズグループが詳しい。

SUSv3のthread un safeな関数一覧

localtime()やgettime(),getenv()等、thread safeにすべきではない関数一覧。SUSv3のthread safeなfunction(TSF)な一覧は存在しないが、Rationaleとして定義が見つかる。

SUSv3のsignal action

signalを受けたときに実行しても良い関数一覧が取れます。

Boost C++ Libraries

次世代C++(C++0x)に取り込まれるライブラリなどを収録する強力なテンプレートライブラリ群。スマートポインタやthread、そして非同期通信など。C++と言う言語が向かう先の指標でもある。

• リーダ： 竹林（id:suigintoh）
• サブリーダ： 中居（id:shin_kusanagi），近藤（id:kondoh86）

主な仕事

• プロジェクト全体の統括
• 各種権限付与
  • 各ツールのアクセス権限付与
  • プロジェクトメンバの登録・削除処理
• ML 会員管理
  • 配送例外に関する処理
• 規約とりまとめ

ファイルリリース・リポジトリ管理

• 正： 立石（id:ktateish）
• 副： 森下（id:tmorishit），竹林（id:suigintoh），田沼（id:tanuma）

主な仕事

• レポジトリの構成管理
  • ブランチ・タグの管理
  • レポジトリの新規作成
  • リリース日の決定
• リリースにむけたパッケージング（spec，changelog 修正含む）
  • ブランチどうしのマージ
  • リリースファイルの作成

ドキュメント・Web サイト管理

• 正： 近藤（id:kondoh86）
• 副： 紅林（id:mkurebayashi），杉浦（id:jsugiura）

主な仕事

• 各種文書類のメンテナンス
  • 各種文書（ http://sourceforge.jp/projects/ultramonkey-l7/docman/ ）の管理
• プロジェクト Web サイトのメンテナンスおよび管理
  • プロジェクト web サイト（ http://ultramonkey-l7.sourceforge.jp/ ）の管理

チケット・課題管理

• 正： 森下（id:tmorishit）
• 副： 高丸（id:takamarua），田沼（id:tanuma）

主な仕事

• 課題管理・スケジュール管理
  • ticket 管理
  • マイルストン管理
  • 未完了課題に対するケツ叩き

渉外・広報管理（権利関係管理含む）

• 正： 福島（id:fukushima）
• 副： 中居（id:shin_kusanagi），近藤（id:kondoh86）

主な仕事

• 渉外・宣伝活動
  • 運営や対外活動に関する受付など．
  • 外部のメンバへの呼びかけなど

• UltraMonkey-L7 - http://sourceforge.jp/projects/ultramonkey-l7/wiki/20090309release/attach/2.1.2-0.zip
  • sslid モジュールに replication 機能追加（gcc 4 以上が必要）
  • プロトコルモジュール追加（過去あった分＋ip）
    • cpassive（Cookie passive）
    • crewrite（Cookir rewrite）
    • ip（Source IP）
    • pfilter（Packet filter）

• UltraMonkey-L7 - http://sourceforge.jp/projects/ultramonkey-l7/wiki/20090127release/attach/ultramonkey-l7-2.1.1-0.zip
  • sslid モジュールは，既存のものを hash 化
    • ただし，replication は未実装のため，2 月中旬を目処に実装．申し訳ありません．
  • Fast Schedule を実装
    • 12 月リリースに漏れていた分．マージミスです．申し訳ありません．

• sslproxy - http://sourceforge.jp/projects/ultramonkey-l7/wiki/20090127release/attach/sslproxy-1.0.1-0.zip
  • 設定項目追加
    • キャッシュの使用有無
    • タイムアウト時間
    • テーブルサイズ
  • rpm は boost 1.36 をベースに作成
    • 1.37 がインストールされた環境では動かないことが発覚．
      • ドキュメントへの反映が必要
      • 本件，次回リリースで対応できるか要検討

l7vsd

• （担当者決定）sessionless モジュール修正
  • サーバからの応答が先行するプロトコル（SMTP 等）にも対応

• （担当者決定）sslid モジュール修正
  • 線形リストをハッシュに変更し高速化

• （担当者決定）l7vs_conn_busy 修正
  • iomux_mod 無効化 → r941 で修正済み

l7directord

• （担当者決定）negotiate チェック（https）のタイムアウト有効化
• （担当者決定）checkcount 有効化
• （担当者決定）getprotobyname 無効化

sslproxy

• （担当者決定）新規追加

SNMP Agent

* （担当者決定）新規追加 削除

ファイルつくりました．

http://sourceforge.jp/projects/ultramonkey-l7/wiki/UML7-2.x-sachiel/attach/sslproxy-1.0.0-0.zip

http://sourceforge.jp/projects/ultramonkey-l7/wiki/UML7-2.x-sachiel/attach/ultramonkey-l7-2.1.0-0.zip

UltraMonkey-L7 の設定管理を行う GUI 画面に関する説明を記載しています。

概要

UltraMonkey-L7 の GUI は、Web ブラウザ経由で UltraMonkey-L7 のステータス・設定状況の確認、設定の変更、クラスタの切り替えなどが行えます。

GUI 機能一覧

現在 GUI に実装されている機能と、サーバで直接操作しなくてはならない機能を以下にまとめます。

機能	GUI実装
GUI へのマルチユーザログイン	○
UltraMonkey-L7 関連プロセスの状態表示	○
UltraMonkey-L7 関連プロセスの起動・停止	×
VirtualServiceの設定表示	○
VirtualServiceの設定変更	△(*1)
VirtualServiceの設定保存	○
VirtualServiceのスループット表示	×
監視プロセスの設定表示	○
監視プロセスの設定変更	○(*2)
監視プロセスの設定保存	○
パーシステンス情報等の同期機能の停止・再開	○
パーシステンス情報等の同期機能の基本設定表示	○
パーシステンス情報等の同期機能の基本設定変更	○
パーシステンス情報等の同期機能のメモリ領域表示	○
パーシステンス情報等の同期機能のメモリ領域変更	×
パーシステンス情報等の同期機能の即時反映	○
パーシステンス情報等の同期機能のデータダンプ実行	×
本体プロセス(l7vsd)のログ表示	○
本体プロセス(l7vsd)のログレベル表示・変更	○
本体プロセス(l7vsd)のログレベル保存	○
本体プロセス(l7vsd)のログ出力先の表示・変更	×
本体プロセス(l7vsd)のログローテート設定の表示・変更	×
設定管理コマンド(l7vsadm)のログ表示	○
設定管理コマンド(l7vsadm)のログレベル表示・変更	○
設定管理コマンド(l7vsadm)のログレベル保存	○
設定管理コマンド(l7vsadm)のログ出力先の表示・変更	×
設定管理コマンド(l7vsadm)のログローテート設定の表示・変更	×
監視プロセス(l7directord)のログ表示	○
監視プロセス(l7directord)のログレベル表示・変更	×
監視プロセス(l7directord)のログ出力先の表示・変更	○
GUIのログ表示	○
GUIのログレベル表示	○
GUIのログレベル変更	×
設定ファイル同期ツールのログ表示	○
設定ファイル同期ツールのログレベル表示	○
設定ファイル同期ツールのログレベル変更	×
クラスタソフトのログ表示	○
GUIのログインユーザ作成	○
GUIのログインユーザ変更	○
GUIのログインユーザ削除	○
クラスタ構成の状態表示	○
クラスタの切り替え	○
クラスタ間での設定の同期	○

(*1)VirtualSerivce や RealServer の指定は IP アドレスのみで、FQDN やホスト名での指定はできません
(*2)GUI の動作に影響がでるため、autoreload 設定のみ変更できません

クライアント条件

• Cookie, JavaScript が有効な Web ブラウザ
• 動作確認済みブラウザ
  • InternetExplorer 6.0 以降
  • Firefox 2.0 以降

GUI インストールサーバ条件

• 以下のソフトウェアがインストールされていること
  • UltraMonkey-L7
  • J2SE 5.0
  • Apache Tomcat 5.5
  • Heartbeat2 (クラスタ構成の操作をする場合のみ必要)
• 詳細については、以下のページをご確認ください
  • UltraMonkey-L7 GUI 動作に必要なライブラリ

その他

• GUI インストール後の初期アカウントは以下のとおりです。
  • ユーザID : ultra
  • パスワード : monkey

UltraMonkey-L7 GUI を動作する上で必要となるライブラリについて記載しています。

必須ライブラリ

J2SE 5.0

• GUI や設定ファイルの同期ツールで必要となります
• ダウンロードURL : http://java.sun.com/j2se/1.5.0/ja/download.html

Apache Tomcat 5.5

• GUI は JSP/Servlet で実装されていますので、動作上必要となります。
• プロジェクトURL : http://tomcat.apache.org/
• ダウンロードURL : http://tomcat.apache.org/download-55.cgi

その他

• GUI は UltraMonkey-L7 インストール済みのサーバにインストールする必要があります。（⇒ UltraMonkey-L7 インストールマニュアル）
• GUI でクラスタ状態の確認やクラスタの切り替えなどを行う場合は、クラスタソフトとして Heartbeat2 をインストールする必要があります。（⇒ UltraMonkey-L7 Heartbeat2 環境インストールマニュアル）

UltraMonkey-L7 の RealServer 監視を行うプロセス l7directord に関する説明を記載しています。

UltraMonkey-L7 の負荷分散を行うプロセス l7vsd に関する説明を記載しています。

UltraMonkey-L7 を動作する上で必要となるライブラリについて記載しています。

必須ライブラリ

glib2

• l7vsd 本体の動作時に必要です。
• プロジェクトURL : http://www.gtk.org/
• ダウンロードURL : http://ftp.gnome.org/pub/gnome/sources/glib/

log4cxx

• l7vsd 本体のログ出力で使用します。
• プロジェクトURL : http://logging.apache.org/log4cxx/index.html
• ダウンロードURL : http://logging.apache.org/log4cxx/download.html
• log4cxx のインストールには以下の apr, apr-util ライブラリが必要になります。
  • apr / apr-util
    • プロジェクトURL : http://apr.apache.org/
    • ダウンロードURL : http://apr.apache.org/download.cgi

Boost C++

• l7vsd 本体をビルドする際に必要です。
• Boost のヘッダファイルのみ利用していますので、必ずしも Boost をビルドする必要はありません。
• プロジェクトURL : http://www.boost.org/
• ダウンロードURL : http://www.boost.org/users/download/

その他のライブラリ

Perl ライブラリ

• l7directord による RealServer 監視時に以下のライブラリのインストールが必要となる場合があります。
  • libwww-perl (LWP::UserAgent, LWP::Debug)
    • l7directord の動作上、必須となる HTTP のモジュールです
    • CPAN URL : http://search.cpan.org/dist/libwww-perl/
  • Net::Ping
    • l7directord の動作上、必須となる Ping のモジュールです。
    • Perl 5.2 以上にバンドルされています。
    • CPAN URL : http://search.cpan.org/dist/Net-Ping/
  • Crypt::SSLeay
    • l7directord で HTTPS による監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/Crypt-SSLeay/
  • libnet (Net::FTP, Net::SMTP, Net::POP3)
    • l7directord で FTP/SMTP/POP3 による監視を行う際に必要となるモジュールです。
    • Perl 5.7 以上にバンドルされています。
    • CPAN URL : http://search.cpan.org/dist/libnet/
  • Mail::IMAPClient
    • l7directord で IMAP による監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/Mail-IMAPClient/
  • perl-ldap (Net::LDAP)
    • l7directord で LDAP による監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/perl-ldap/
  • DBI
    • l7directord で PostgreSQL, MySQL の監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/DBI/
  • DBD::Pg
    • l7directord で PostgreSQL の監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/DBD-Pg/
  • DBD::mysql
    • l7directord で MySQL の監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/DBD-mysql/
  • Net::DNS
    • l7directord で DNS による監視を行う際に必要となるモジュールです。
    • CPAN URL : http://search.cpan.org/dist/Net-DNS/

UltraMonkey-L7 を動作する上で必要となる環境について記載しています。

動作条件

高可用サイト推奨環境

(*)ACT-STANDBY冗長化構成時には上記構成が 2 環境必要になります

LEVEL

サンプル

A

B

C

D

E

Endpoint
IPアドレスとPORTのセットを指す。ネットワークのコネクションはエンドポイントとエンドポイントの間となる。

F

G

H

I

J

K

L

M

Module
共有オブジェクトを利用し実行時に動的に処理コードを追加や削除を行える部分。ProtocolModuleとScheduleModuleの二種類が存在する。これらはModule管理で管理される。

N

O

P

ProtocolModule
OSI7層モデルの7層目を解析し、処理を行う各共有オブジェクト群を指す。プロトコルに対応した各種のModuleが用意される。新しいプロトコルへの対応はUltraMonkey-L7本体のリコンパイルの必要はなく、Moduleを追加することにより実現できる。

Q

QoS
帯域を制限する機能。UltraMonkey-L7ではVirtualServiceをひとつの単位として帯域制御の設定を行うことができる。RealServerへの帯域制御とVirtualServiceへ接続する!Client全体の帯域制御である。

R

RealServer
UltraMonkey-L7が透過的にサービスを行う実際のエンドポイントを指す。UltraMonkey-L7はクライアント側のEndpointとRealServerの間に入り、複数のReadServerがあるのをクライアント側に意識させずに負荷分散とセッション管理を行う。

S

ScheduleModule
RealServerへの振分けを行うスケジューリングを受け持つModule。

SorryServer
サービスが継続できなかった場合などにその旨を伝えるコンテンツを持つEndpoint。
UltraMonkey-L7では一定の条件をもってVirtualServiceごとにSorryへとClient毎の接続を中継するが、手動で!Sorry状態への変更も可能。

T

U

V

VIP
VirtualService を提供する IP アドレスのこと。IP アドレスとポート番号をあわせて VIP と呼ぶこともある。
Heartbeat などを使用して現用系に VIP を付与し、そこに VirtualService を括り付けることで、Act-Standby 高可用構成を構築することが可能となる。

VirtualService
UltraMonkey-L7で管理されるサービスの単位。ひとつのVirtualServiceにつきひとつのProtocolModuleとひとつのScheduleModuleを指定できる。QoSもVirtualServiceの単位で設定可能。

W

weight
ScheduleModule全般では1/0の二値を用いてRealServerへの振分けの可否を決定する。ただしWeightRoundRobinModuleでは任意の整数での重み付けを解釈し、各RealServerへの振分け頻度をweightを使って制御する。

X

Y

Z

あ

か

仮想 IP アドレス
VIP を参照。

さ

た

な

は

プロトコルモジュール
ProtocolModule を参照。

ま

や

ら

リアルサーバ
RealServer を参照

わ

l7directord設定項目

Global Setting

• checktimeout
  • 監視ノードから何秒間正常な応答が得られなかった場合にダウンとみなすか
  • デフォルト 5 秒
  • 条件 checktype が connect, ping の場合、または checktype が negotiate で service が sip, dns の場合
  • virtual section での上書き可能
• negotiatetimeout
  • 監視ノードから何秒間正常な応答が得られなかった場合にダウンとみなすか
  • デフォルト 0 秒（これはまずそうな予感。Default is defined by the operating system. と doc に書かれているがそうはみえない）
  • 条件 checktype が negotiate で service が http, https, smtp, pop, imap, ldap, nntp, ftp の場合
  • virtual section での上書き可能
• checkinterval
  • 監視間隔の秒数
  • デフォルト 10 秒
• checkcount
  • 監視ノードから何回連続で正常な応答が得られなかった場合にダウンとみなすか
  • デフォルト 1 回
  • 条件 checktype が ping の場合のみ
• autoreload
  • 設定ファイルを定期的にチェックして変更があった場合に、変更内容を反映するかどうか
  • デフォルト no
• callback
  • 設定ファイルを定期的にチェックして変更があった場合に、実行するプログラム
  • デフォルト undef
  • autoreload の値にかかわらず、設定ファイルが変更された場合に、</path/callback> </path/config> が実行される
• fallback
  • real サーバが全てダウンした際に追加される real サーバの代替サーバ
• logfile
  • l7directord のログファイルの指定
  • デフォルト /var/log/l7directord.log
  • 最初の文字が / 以外だと syslog の facility として扱う
• execute
  • 設定ファイルとして規定されているパス以外のものを使う場合にここに記述する
  • 自動的に検索する設定ファイルのパスは以下
    • /etc/ha.d/l7directord.cf
    • /etc/ha.d/conf/l7directord.cf
• supervised
  • デバッグモードと同じでデーモンにならず、ログが標準出力に出力される
  • daemontools(12) を使う場合に便利だそうです。
• quiescent
  • real サーバがダウンした際に、weight を 0 に変更する(yes)か、仮想サービスから取り除く(no)か
  • デフォルト no
  • virtual section での上書き可能
• virtual
  • 仮想サービスとする IP アドレスとポート番号を指定する
  • 仮想サービス毎の詳細設定は以下の Virtual Section Setting を参照

Virtual Section Setting

• real
  • real サーバの IP アドレスとポート番号の設定
  • オプションとしてサーバの weight, 以降で述べる request, receive のペアの設定も可能
  • forwarding の方法は masq のみ設定可能
  • IP アドレスは範囲指定も可能（192.168.0.1->192.168.0.100など）
  • 例
    • real = 192.168.0.2:80 masq
    • real = 192.168.0.3:80 masq 1
    • real = 192.168.0.4:80 masq 1 "check.html", "Test"
    • real = 192.168.0.5->192.168.0.10:http masq
• module
  • プロトコルモジュールの指定
  • l7vsadm では省略可能なプロトコルモジュールのキーになるオプションもここでは省略不可
  • 現在設定可能な組み合わせは以下
    • pfilter --path-match
    • url --pattern-match
    • urla --key-name
    • cpassive --cookie-name
    • crewrite --cookie-name
    • cinsert --cookie-name
    • chash --cookie-name
• maxconn
  • 仮想サービスで扱える最大のコネクション数
  • 超過した場合、sorryserver へリダイレクトされる
• qosservice
  • 仮想サービスでの帯域制限の値(bps)
  • K, M, Gの単位も利用可能
• qosclient
  • 単一コネクションでの帯域制限の値(bps)
  • K, M, G の単位も利用可能
• sorryserver
  • maxconn の上限を超えた際にリダイレクトされるサーバの IP アドレス、ポート番号の設定
• checktype
  • real サーバの監視方法の設定
  • 以下が設定可能な値
    • negotiate
      • 特定の request を送り、特定の receive 文字列を受信することでサーバの確認を行う
      • 確認方法は以降の service に依存する
    • connect
      • TCP/IP コネクションを張って確認する
    • 数字
      • negotiate と connect の併用で、入力した数字回の connect 確認の後で 1 回の negotiate 確認を行う。
    • ping
      • ICMP で ping 確認を行う
    • off
      • 監視を行わないし、設定した real や fallback サーバはダウンしているものと扱われる
    • on
      • 監視を行わないが、設定した real や fallback サーバはアップしているものと扱われる
  • デフォルトは negotiate
• service
  • checktype が negotiate の場合の real サーバの監視方法の設定
  • ftp, smtp, dns, http, pop, nntp, imap, ldap, https, mysql, pgsql, sip, none が設定可能
  • none は何もせず、常にアップと判断する
  • デフォルトは仮想サービスのポート番号に依存し、21, 25, 53, 80, 110, 119, 143, 389, 443, 3306, 5432, 5060 の場合は上記のサービスがデフォルトとなるが、それ以外の場合は none がデフォルトとなる
• checkport
  • 監視するポート番号を指定する
  • デフォルトは real サーバのポート番号
• request
  • 監視の際に使うリクエスト用の設定
  • service が http, https, ldap, mysql, pgsql, ftp, dns の場合に使われる
• receive
  • 監視の際に使うレスポンス解析用の設定
  • service が http, https, ldap, ftp, dns の場合に使われる
• httpmethod
  • http, https の監視の際に使う HTTP メソッドの設定
  • GET, HEAD の指定が可能
  • デフォルトは GET
• virtualhost
  • http, https の監視の際に使う virtual host の設定
• login
  • ftp, pop, imap, mysql, pgsql, sip の場合に使われる login ユーザ名の設定
• passwd
  • ftp, pop, imap, mysql, pgsql, sip の場合に使われる login パスワードの設定
• database
  • mysql, pgsql で利用する database 名の設定
• scheduler
  • 利用するスケジューラの設定
  • 利用可能なスケジューラは rr, wrr, lc
  • デフォルトは rr
• protocol
  • 利用するプロトコルの設定で tcp のみ設定可能

通常運転時に監視したいLogを埋め込む。起動ログや操作ログが該当する。

• 起動/終了
• 操作(サービス追加/削除やRealServerの追加/削除等)

注意:signalを受信したときにはlogを出力してはならない。MultiThread環境下ではSignalSafeな関数のみを呼び出すことが可能だが、その数は非常に限定される。malloc()やprintf()でさえもSingalUnSafeな関数のため、signal handler内部で出来ることは内部のグローバル変数書き換えのみと思ったほうが良い。

example(ただしdebuglogは省略).

    int main( int argc, char* argv[] ){
      logputINFO( CATEGORY_SYSTEM, "program start." );
      logputINFO( CATEGORY_SYSTEM, "switch daemon" );
      daemon();
      for(;;){
        ...
      }
      logputInfo( CATEGORY_SYSTEM, "program terminate nomal." );
      return 0;
    }

---

Debugで出力するLogは基本的に以下の情報を出力する。

• 関数の入通知と引数のダンプ
• 関数の出通知と返値のダンプ
• メモリ確保時(malloc)のメモリサイズとアドレス
• メモリ開放時(free)のメモリアドレス
• ポインタの先に代入する場合にはそのポインタの型と内容
• iomuxの状態変更時の変更前と変更後の内容
• 重要なシステム関数を呼ぶ場合(ioctl()等)にその関数名と引数のダンプ
• 通信データダンプ(16進表示)

　　　　以下必要な情報は随時追加

---

---

example.

  int foo( int integer, char* name, struct sct_t* t ){
    int* ptr = NULL;
    if( DEBUG == get_log_level() ){
      char buf[256];
      memset( buf, NULL, sizeof(buf) );
      sprintf( buf, "function foo(int, char* struct sct_t* ) in "
                    " int value = %d "
                    " char* value = %s"
                    " struct sct_t* address = %x"
                    "  sct_t.x = %d "
                    "  sct_t.y = %d " ,
                    integer, name, (intptr_t) t, t->x, t->y );
      logputDEBUG( CATEGORY_LOGIC, buf );
    }
    ptr = malloc( sizeof(int) );
    if( DEBUG == get_log_level() ){
      char buf[256];
      memset( buf, NULL, sizeof(buf) );
      sprintf( buf, "memory allocate address: %x, size :%d" , (intptr_t) ptr, sizeof(int) );
      logputDEBUG( CATEGORY_LOGIC, buf );
    }
    if( !ptr ){
      logputERROR( "don't allocate memory" );
      if( DEBUG == get_log_level() ) logputDEBUG( "function foo() return -1" );
      return -1;
    }
    free( ptr );
    if( DEBUG == get_log_level() ){
      logputDEBUG( "memory free address: %x, size :%d", (intptr_t) ptr, sizeof(int) );
      logoutDEBUG( "return function foo() return 0" );
    }
    return 0;     
  }

OS設定関係

環境関係