質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.53%

サーバ構築

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 3
  • VIEW 985

ikasoumen

score 101

前提・実現したいこと

大量(数百台)のサーバ(インフラ)を構築(オンプレミス)することになりました。

まだ、正式に参画していないので導入するOSのそこまで詳しい情報はありませんが、
Active Directoryなど使うといっていたのでWindowsServerを使うのは間違いなく、他のアプリケーションでlinux系のサーバが使われるのではと想定しています。

人力でやるのは設定ミスなど多発しそうなので、
サーバの設計・構成の管理・適用を行うツールなどを利用したいと思っているのですが、そういったもののデファクトスタンダードとなるようなツールは存在するのでしょうか?

また、サーバのOS設定の設計はどのような思想を持てばいいでしょうか?

例えば、

  • IPのセグメントはどんな単位でグループ(マスク)するか?
  • どんなユーザ・グループを作り、フォルダや各サーバへのSSHのアクセス権を適用するか
  • パッケージの管理は誰がやるか(インフラと開発チームで分けて管理した方がよい?)
  • ログ出力先
  • 各サーバで共通的に利用するのに必要な環境変数やシェルはどんなのが考えられるか?
  • アプリケーションのサーバを冗長化し、2台並べるとき、環境コピー・個別の設定の適用はどのような方法が楽か?
  • 共通化していいところ・わるいところ

など、分からないことだらけなのですが、気を付けていることなどありましたら教えていただきたいです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • ttyp03

    2016/06/21 09:54

    回答でなくて申し訳ありません。数台のサーバーに対して数百台のクライアントという環境なら割と良くありますけど、数百台のサーバーを必要とする業務ってどんなのですか?興味があるので差し障りのない範囲で教えてください。

    キャンセル

  • ikasoumen

    2016/06/22 07:19

    例えば、株取引のサービスを提供しようとしたらこんな規模では済まないのではないでしょうか。

    キャンセル

  • ttyp03

    2016/06/22 08:58

    なるほど、株取引ですか。ありがとうございました。

    キャンセル

回答 3

checkベストアンサー

+1

Active Directoryなど使うといっていたのでWindowsServerを使うのは間違いなく、他のアプリケーションでlinux系のサーバが使われるのではと想定しています。

認証統合をされたいのであれば、Windows MS Active Directory または、samba4 ldapを認証基盤とし、他WindowsOS、LinuxOS、他アプリケーションの認証を統合とする方式が挙げられると思います。
認証基盤を管理される方のレベルに合わせてプラットフォームを選択する必要があると考えます。

人力でやるのは設定ミスなど多発しそうなので、 
サーバの設計・構成の管理・適用を行うツールなどを利用したいと思っているのですが、そういったもののデファクトスタンダードとなるようなツールは存在するのでしょうか?

設計におけるツールの存在は確認していませんが、Linux系サーバの大量展開における構成管理/構築については構成管理フレームワークを使用するのが一般的です。
cf-engine、chef、puppet、ansible等。
Windowsも含めるならansibleがいいかもです。

IPのセグメントはどんな単位でグループ(マスク)するか?

存在するネットワークノード数を割り出し、使用するクラスを決定する。
クラス、マスクの設計は、セキュリティ面と拡張性の兼ね合いで決定します。
セキュリティ面を考慮するのであれば、余計なノードが介在できないマスクを採用する場面もあります。
拡張性を考慮するのであれば、広めにマスクを切ることも考慮します。
あとは、ルーティングの兼ね合いで、IP形体を決定します。(これは細かい話になるので、ここでは割愛)

どんなユーザ・グループを作り、フォルダや各サーバへのSSHのアクセス権を適用するか

基本的には、人為的ミスが起こりにくい、判別しやすいものを採用すべきと考えますが、用途によって変ってくると思います。
例えば、苗字1部+氏名とした場合、高校の例を挙げると毎年登録する必要性がでてきます。
これをIDとすると、3学年分のIDを用意するのみで、毎年の登録の手間が省けるなど。
システム要件と照らし合わせて設計すべきと考えます。
グループも同様と考えます。
ただし、アクセス権等の設定はグループ単位で行えるほうが効率が良いと思うので考慮して設計すべきと考えます。

パッケージの管理は誰がやるか(インフラと開発チームで分けて管理した方がよい?)
開発側のパッケージはセンシティブなので、開発チーム側に任せるべきと考えますが、開発チームがインフラに詳しい方でない場合は申請するような仕組みを作りインフラ側で管理するのも良いと思います。

ログ出力先

Linux系のログはsyslog転送の仕組みを使って、1つのサーバに纏めると管理しやすいと思います。
その場合、ディスク容量のサイジングが必要になります。
Windowsは好みですね。Windows側でもsyslog転送できるツールがあれば、Linuxに転送するのもありです。(文字コードとか気をつける必要がありそうですが...)
Linux系において追加したログについては、ログローテートをすることを忘れずに。

各サーバで共通的に利用するのに必要な環境変数やシェルはどんなのが考えられるか?

何をしたいかに拠ります。広義すぎてご回答差し上げることができません。

アプリケーションのサーバを冗長化し、2台並べるとき、環境コピー・個別の設定の適用はどのような方法が楽か?

Windowsであれば、MSFC、WSFCまたは、サードパーティ性のクラスタソフトウェアで実現できると思います。
Linux系であれば、Hertbeat、HA、Pacemaker、DRBDなどでしょうか。

共通化していいところ・わるいところ

共通化って何を共通と定義しているのでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/06/22 07:16

    ありがとうございます。
    とても参考になります。
    インフラ設計は学習範囲が広くて大変そうです。。
    一番心配なのはネットワーク構成図のお絵かきすることです。

    共通化というのは、
    スケールアウトや冗長化構成でサーバAをクローンしたサーバBを作るとして、
    サーバBがそのまま動いてくれれば理想ですが、
    個別の設定やシェルを叩く必要があると思います。

    そうすると設定ミスなどあるかもしれないので、
    個別に設定しないでする方法や
    苦労した経験則・テクニックなどがありましたら、教えていただきたいなと思った次第です。

    キャンセル

  • 2016/06/22 09:20

    > スケールアウトや冗長化構成でサーバAをクローンしたサーバBを作るとして、
    > サーバBがそのまま動いてくれれば理想ですが、
    > 個別の設定やシェルを叩く必要があると思います。
    このミスを軽減するのも構成管理フレームワークの強みだと思います。
    ただ、構成管理フレームワークを設定するのも人なので、検証を重ね、構築ドキュメントを整備して望んでも、作業落ち/ミスはある程度発生してしまいます(経験上)。

    キャンセル

  • 2016/06/24 11:41

    ありがとうございます。

    ツールの使い方を覚えて、現場で提案できるように頑張ります。

    キャンセル

+1

このプロジェクトにおけるポジションが良く分かりません。発注者?受注者?PM?メンバー?
また、質問の範囲が広すぎて、あなたの担当箇所が不明です。
ちゃんとあなたの責任範囲を確認すべきです。もっと狭いはずです。

また、質問されている点は枝葉でしかありません。

もっと根源的なポリシーの決定から手を付ける必要があります。
例えば、以下の様な項目
・セキュリティポリシー
・運用ポリシー
・設計/冗長化ポリシー

その後、各レイヤー間における要件を整理し、その要件を各レイヤーが満たすことができるか、検討することになります。満たせなければ、実現できる範囲で各レイヤー間の調整を行います。
その中で、あなたの担当するレイヤーの要件が確定します。

各レイヤー間の要件を満たすかどうかの判断はかなりのナレッジが必要です。
そのナレッジに関して、ここで質問することは有意義かと思いますが、今の質問ではあなたに意味のある回答はつかないと思います。
一度整理されては?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/06/24 11:37

    要件の定義はこれからです。

    担当する範囲は確かにありますが、
    範囲外だから知らなくていいというのは、
    経験上、必ず後になってから知らなかった分のしわ寄せがこちらにくるので嫌です。

    キャンセル

  • 2016/06/24 13:33

    時間に余裕が有るのであればまんべんなく学習すれば良いかもしれませんが、多分お急ぎですよね?
    ご自身のほしい情報を見極めて質問されることが、今必要なアクションかと。

    例えば、要件定義の段階で、あなたが発注者でインフラのPMであった場合、
    ・IPのセグメントはどんな単位でグループ(マスク)するか?
    に対して、必要な情報は以下になります。
    ・要件を定義するに当たり、サーバ間の制御としてどのようなネットワークを構築するべきか?
    ここにはサーバ間の連携要件やセキュリティポリシー、運用/監視方法が関わってきます。それぞれに担当部門が違うはずなので、各部門との調整やキーとなる考え方の習得がPMの役割となります。

    あなたの立場が違い、受注者でメンバーであった場合
    ・IPのセグメントはどんな単位でグループ(マスク)するか?
    に対して、必要な情報は以下になります。
    ・過去事例から似たプロジェクトで炎上箇所としてセグメント割はなかったか
    ・提案機器やOS、ミドルウェアを想定し、その実性能はどの程度であるかの把握
    発注者が受注者に求めるのは、事例や実績、発注側ではわからないホントのところです。そういった情報に真摯に対応できるよう準備をすることが必要です。

    上記はあくまで例なので、実際とは異なりますが、回答する側からすると質問者の立場がわからないと役に立つ回答が出来ません。

    何より、せっかく回答してもあなたの役に立たないのであれば、あなたの質問は回答者の時間ばかり使ってしまう迷惑なものになります。

    一般的にインフラ屋さんは、上位の要件により、プロジェクト中振り回される傾向にあります。特に担当するレイヤーが下位になればなるほど、情報伝達も遅れるので、大きく振り回されます。

    それを回避するために、ポリシーの決定時に、十分な議論をし、責任範囲において振り回されることが無いよう予防線を張ることが必要なのですが、そこに必要な情報は立場によって違います。

    ご自身の立場を明確にし、質問ポイントを整理されはいかがですか?

    キャンセル

  • 2016/06/26 11:56

    ありがとうございます。

    やはり、ネットワークとセキュリティにかかわる構成が一番重たいです。

    立場上、PMというわけではないですが、プロジェクトの早い段階からの参入なので、
    広く知識を持てば広く立ち回れるため、参考書では想像しにくい、実際の運用・設計などどのようになっているか感覚を磨いておきたいです。

    実際全てに手を回せるわけではないので、
    立場を明確にし、まずは自身の責務をこなさなければいけないというのは理解してます。

    しかしながら、現場入りしていないので、具体的にどこまで担当させられるかはまだ明確ではありませんので、入場してからまたご質問するかもしれません。

    キャンセル

0

もし決まっているようでしたら、サーバの環境(OSなど)を記載した方がいいかもしれません。以下のページ(Linuxですが)が参考になると思います。
環境構築自動化の手順と評価検証

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/06/21 08:51

    ありがとうございます。
    詳しい情報ではありませんが説明を追記いたしました。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.53%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる