LinuC レベル3 3PS試験のサンプル問題（本番形式・解説付き）

LinuC レベル3 3PS試験（LPI-Japan・LinuC-3PS（プラットフォームスペシャリスト））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（60問）の冒頭から抜粋したオリジナル問題です。当サイトは全670問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

仮想化基盤の集約率を上げるため、ゲストへ渡すディスクを実際に書き込んだ分だけ消費させ、さらにバックアップを取る前の状態をイメージファイル自身の中にスナップショットとして保持したい。保管時には圧縮も効かせたく、生の書き込み性能がわずかに落ちることは許容する。この要件に合う仮想ディスクイメージ形式の名称を入力せよ。

入力形式（コマンドを打ち込んで答える問題です）

QCOW2（正解）

別解: qcow2 ／ Qcow2 ／ QCow2

解説

QCOW2 は形式の中にメタデータの層を持ち、実際に書き込んだ分だけ領域を消費する遅延割り当て、イメージ内部のスナップショット、圧縮に対応する。RAW はその層を持たずディスクの内容をそのまま置くため、オーバーヘッドが小さい代わりに、スナップショットや圧縮は形式の外側の仕組みへ任せることになる。集約率と機能を取るか、生の I/O 性能を取るかで選び分ける。

設問2

OSD を 30 台持つクラスタで、レプリカ数 3 のプールを 1 つ作り、そこへ全容量を割り当てる計画がある。このプールの配置グループ数の決め方として、最も適切なものはどれか。

配置グループ数は OSD 台数と一致させる決まりであり、pg_num を 30 に設定する。
配置グループ数が多いほど分散が良くなるため、pg_num を OSD 台数の 1000 倍にあたる値まで引き上げておく。
OSD あたりの配置グループ数が推奨される範囲に収まるよう総数を見積もり、2 の冪に丸めた値を pg_num に設定する。（正解）
配置グループはプールごとに 1 つだけ持つ設計であり、pg_num は 1 のままにして CRUSH 側の重みで分散を調整する。

解説

pg_num は「目標とする OSD あたりの配置グループ数 × OSD 台数 × そのプールが占めるデータ比率 ÷ レプリカ数」で見積もり、CRUSH の計算効率のために 2 の冪へ丸める。少なすぎると各 OSD の使用量が偏り、多すぎると OSD 1 台あたりのメモリと CPU の負担が増える。配置グループは OSD へオブジェクトを束ねて割り当てるための中間単位であり、OSD 台数やレプリカ数と 1 対 1 に決まる値ではない点が要点になる。

他の選択肢が誤りである理由

「配置グループ数は OSD 台数と一致させる決まりであり、pg_num を 30 に設定する。」配置グループ数を OSD 台数と一致させる決まりはない。この値では分散の粒度が粗すぎて、OSD ごとの使用量に偏りが出やすくなる。
「配置グループ数が多いほど分散が良くなるため、pg_num を OSD 台数の 1000 倍にあたる値まで引き上げておく。」配置グループを過剰に増やすと、OSD 1 台あたりが抱える配置グループのメモリと CPU の負担が跳ね上がり、ピアリングや復旧の所要時間も悪化する。
「配置グループはプールごとに 1 つだけ持つ設計であり、pg_num は 1 のままにして CRUSH 側の重みで分散を調整する。」配置グループが 1 つでは、そのプールのオブジェクトがすべて同じ OSD の組へ載ることになり、分散も並列性も得られない。

設問3

外部のデータセンターに置かれた Web サイトを Web シナリオで監視したい。サイトのサーバーには自社の管理権限がなく、ソフトウェアを追加することもできない。この監視の成立に関する説明として正しいものはどれか。

シナリオは Zabbix サーバーが実行するので、監視対象側への導入は不要である（正解）
監視対象側にエージェントを導入し、そのエージェントがシナリオを実行する構成となる
監視対象側で SNMP を有効にしなければ、Zabbix サーバーからシナリオを実行できない仕様である
シナリオを持たせるためのホストを作れないので、外部チェックのスクリプトで代替することになる

解説

Web シナリオはサーバー（またはプロキシ）が HTTP リクエストを送って応答を判定するエージェントレスの監視で、対象側には何も入れずに済む。エージェントの導入を前提とするアイテムとは、値を採る主体がどちら側にあるかで区別される。「監視対象側で SNMP を有効にしなければ、Zabbix サーバーからシナリオを実行できない仕様である」は誤り。Web シナリオは HTTP で完結し、SNMP の有効化を前提としない。Zabbix のホストは監視項目をまとめるための登録単位なので、対象を操作できなくてもホストを作成してシナリオを持たせられる。

他の選択肢が誤りである理由

「監視対象側にエージェントを導入し、そのエージェントがシナリオを実行する構成となる」誤り。シナリオを実行するのはサーバー側であり、監視対象にエージェントを置く必要はない。
「監視対象側で SNMP を有効にしなければ、Zabbix サーバーからシナリオを実行できない仕様である」誤り。Web シナリオは HTTP で完結し、SNMP の有効化を前提としない。
「シナリオを持たせるためのホストを作れないので、外部チェックのスクリプトで代替することになる」誤り。Zabbix のホストは監視項目をまとめるための登録単位なので、対象を操作できなくてもホストを作成してシナリオを持たせられる。

設問4

システムコンテナで運用してきた業務システムを、アプリケーションコンテナへ移す設計を進めている。移行の方針として、最も適切なものはどれか。

常駐する処理を役割ごとに分け、コンテナごとに主となるプロセスを一つ持たせる構成へ組み替える。（正解）
既存の init をそのままイメージに含め、コンテナの中で複数のデーモンを従来どおり起動させる。
状態を持つ処理をコンテナ内部のディスク領域へ集約し、作り直すたびにそこから引き継ぐ設計にする。
ホスト側の init を共有し、コンテナには実行ファイルだけを置いて起動時に読み込む構成へ切り替える。

解説

アプリケーションコンテナは1つのコンテナに主となるプロセスを1つ置く前提で作られており、常駐処理は役割ごとに分割してコンテナへ割り当てるのが移行の筋になる。init を抱えたまま複数デーモンを起動する作りはシステムコンテナの形をそのまま持ち込んだもので、ライフサイクル管理や状態の監視が高レベルランタイム側から効かなくなる。

他の選択肢が誤りである理由

「既存の init をそのままイメージに含め、コンテナの中で複数のデーモンを従来どおり起動させる。」init を含めて複数デーモンを動かす形はシステムコンテナの構成をそのまま移しただけであり、アプリケーションコンテナとして扱う利点が得られない。
「状態を持つ処理をコンテナ内部のディスク領域へ集約し、作り直すたびにそこから引き継ぐ設計にする。」アプリケーションコンテナは作り直しのたびに書き込み層が捨てられる前提であるため、状態をコンテナ内部の領域に集約すると引き継げなくなる。
「ホスト側の init を共有し、コンテナには実行ファイルだけを置いて起動時に読み込む構成へ切り替える。」コンテナは自身の隔離された環境で起動するものであり、ホスト側の init を共有して実行ファイルだけを配置する構成は成り立たない。

設問5

<Proxy balancer://appcluster> ブロックに BalancerMember を 3 行並べて負荷分散を構成した。ここへ lbmethod のようなバランサ全体に効くパラメータを、ProxyPass の行を長くせずに与えたい。書き方として最も適切なものはどれか。

同じ <Proxy balancer://appcluster> ブロックの中に ProxySet lbmethod=bytraffic と書き加える。（正解）
各 BalancerMember の行末に lbmethod=bytraffic を付け、メンバーごとにアルゴリズムを指定する。
ProxyPassReverse の行に lbmethod=bytraffic を付け、復路の書き換えと合わせて指定する。
<Proxy> ブロックの外側で BalancerMember balancer://appcluster lbmethod=bytraffic と宣言する。

解説

ProxySet は <Proxy balancer://...> コンテナの中に書き、lbmethod のようなバランサ単位のパラメータをまとめて設定するディレクティブである。同じ内容は ProxyPass の行末に key=value の形で並べても指定できるが、ProxySet を使えば定義が一箇所に収まる。BalancerMember の行に書けるのは loadfactor などメンバー単位のパラメータで、バランサ全体のアルゴリズムはそこでは決まらない。ProxyPassReverse は応答ヘッダーの書き換えを担うディレクティブで、バランサのパラメータを受け取る口を持たない。「<Proxy> ブロックの外側で BalancerMember balancer://appcluster lbmethod=bytraffic と宣言する」は誤り。BalancerMember はバランサを構成するメンバーを定義するディレクティブで、コンテナの外でバランサ自体を宣言する用途のものではない。

他の選択肢が誤りである理由

「各 BalancerMember の行末に lbmethod=bytraffic を付け、メンバーごとにアルゴリズムを指定する。」BalancerMember に付けられるのは loadfactor などメンバー単位のパラメータで、バランサ全体のアルゴリズムはこの行では決まらない。
「ProxyPassReverse の行に lbmethod=bytraffic を付け、復路の書き換えと合わせて指定する。」ProxyPassReverse は応答ヘッダーの書き換えを担うディレクティブで、バランサのパラメータを受け取る口を持たない。
「<Proxy> ブロックの外側で BalancerMember balancer://appcluster lbmethod=bytraffic と宣言する。」BalancerMember はバランサを構成するメンバーを定義するディレクティブで、コンテナの外でバランサ自体を宣言する用途のものではない。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← LinuC レベル3 3PS試験の資格ページへ