AnsibleでPostgreSQLをインストールする手順も調べたのでメモしておく。前回のPuppetでのPostgreSQLインストール方法の姉妹編である。 環境は * CentOS 7.2 * Ansible 2.0.2.0 Ansibleのインストール Pythonの2.6 or 2.7が必要らしい。
Vagrant.configure(2) do |config| config.vm.define :pgpool01 do |h1| h1.vm.provider "virtualbox" do |v| v.customize ["modifyvm", :id, "--memory", 512] end h1.vm.network :private_network, ip: "192.168.1.11" h1.vm.box = "chef/centos-6.6" h1.vm.hostname = "pgpool01" end config.vm.define :pgpool02 do |h1| h1.vm.provider "virtualbox" do |v| v.customize ["modifyvm", :id, "--memory", 512] end h1.vm.networ
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
6 運用保守 総合行政情報システムにおいては、共通基盤システムだけでなく全ての業務システムも含め、システ ム運用業者によって統合したシステム運用を行うことを想定している。 ここでは、総合行政情報システム全体の運用保守体制や役割分担を明確にし、システム運用業者が行 うべき作業内容や必要とするドキュメントを定義する。 TCO削減 ・運用に必要なものを構築段階から作成することにより、安全なシス テム運用が可能となり、運用保守コストが削減される リスク排除 ・運用設計を確実に行うことで、本市とシステム運用業者間、業務シ ステム保守業者とシステム運用業者間の認識の違いから発生する運 用上のトラブル発生リスクを低減する ベンダロック排除 ・パッケージシステム適用阻害の要件となる事項を最低限にとどめる ことにより、基盤ロックインとならない 業務への要求 ・必要最低限の設計書作成及びシステム運用業者への
編集・発行元 独立行政法人情報処理推進機構(IPA) 技術本部 ソフトウェア高信頼化センター(SEC) 発行日 2013年3月4日 サイズ B5変形判 ページ数 408ページ ISBN 978-4-905318-19-4 定価 1,572円(税込)(紙書籍の販売は終了しました) 書籍概要 概要 「ソフトウェア、システム、サービスに関係する人々が”同じ言葉を話す”ことができるよう、共通の枠組みである「共通フレーム2013」を作成しました。 ソフトウェア、システム、サービスの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組みです。その詳細、使い方を解説しています。 本書は以前の版である「共通フレーム2007第2版」を大きく変更しリニューアルしたものです。主な特徴として以下があります。 ベースとなる国際規格をJIS X 0160:
西澤です。先日"AWS環境へのデータ移行"をテーマに社内で営業向け勉強会を行ったのですが、自分が1から資料を作るよりもずっと有用な公開資料がたくさんあったので、それらを使って説明をさせてもらいました。当日メンバーから出た質問等も補足しながら、今回はその情報をこちらにまとめておきたいと思います。 前提 タイトルではデータベース移行としていますが、こちらではRDBの移行のみを対象とします。AWSの各種サービスの詳しい説明は行いません。それらを組み合わせて利用する際に必要となる情報をまとめたいと思います。また、これからご紹介する資料の中には重複する部分も含まれるのですが、私が個人的によくまとまっているというところをピックアップしてご紹介して行こうと思います。 AWSへのデータ転送方法のまとめ まずは、データファイルの転送方法のまとめです。いつの間にかできていた下記ページが非常にわかりやすくまとま
メインフレームからオープン系になろうとも、また、使う道具やシステムは変わったとしても単に使う道具が変わっただけで、 それらを維持・管理する基本の運用そのものは変わりません。要はそれらの道具をどう人が使い、どう維持・管理するかであり、どんなにいい環境や仕組みを導入・構築、あるいはその環境でどんなにいいシステムを構築したとしても、 それらを維持・管理する運用がしっかりしていなければ、どんなにいい環境やシステムであっても、機能を十分に発揮することはできません。運用は土台であり、また、土地であり、しっかりした基盤の基に木に当たるシステムを構築していかなければ、木は成長しないし、成長させるために手間のかかる煩雑な運用をしなければなりません。 そのような、しっかりした基盤のもとで行う運用であれば、メインフレームもオープン系も運用は同じです。
SAP HANA運用管理ソリューションとは オープンソースソフトウェアの統合運用管理ツールであるHinemosを活用し、SAP HANAの監視や運用自動化を実現する運用管理基盤を構築いたします。Hinemos標準機能の監視、ジョブ管理機能に加えて、SAP HANA特有の監視テンプレート、バックアップや起動停止などの運用自動化フレームワークもあわせて利用できるため、SAP HANAの運用管理をスピーディかつリーズナブルに始めることができます。 概要と特徴 SAP HANAの運用において必要となる監視および運用自動化の機能を、オープンソースの統合運用管理ツールであるHinemosを活用して実装いたします。SAP HANA特有の監視項目や運用ジョブはテンプレートとして提供いたします。これにより短期間での運用基盤の構築が可能です。Hinemosの基本機能は無償で利用することができるため、規模に関わ
はじめまして。開発部のid:guitarrapc_tech です。 今回、黒騎士と白の魔王を例にモニタリングをどのようにしているのか、どのように考えてサービス監視を行っているのか紹介したいと思います。 目次 目次 モニタリング モニタリングの不足 CBT で気づいたモニタリング不足 モニタリングサービスの要件と選定 モニタリングの分類 モニタリングをレイヤー分けして可視化する 1. サービスの全般的な状態 2. アプリケーションと相互関係にあるリソース状態 3. アプリケーションの詳細なメトリクス状態 4. 各ロールの詳細メトリクス イベント アラート まとめ 参考 モニタリング 「黒騎士と白の魔王」の開発からリリースにかけて、大きな課題であり続けたのが「どのようにサービスのモニタリングを行うか」でした。ここでいうモニタリングは、次の意味を持たせています。 役割 意味 現状把握 サービスが
概要 サービスレベルをいかに設計し、いかに運用するか。自分なりの考えの整理です。 尋常ではない長さになりました。随時アップデートします。たぶん。 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) 作者: John Allspaw,Jesse Robbins,角征典出版社/メーカー: オライリージャパン発売日: 2011/05/14メディア: 大型本購入: 10人 クリック: 923回この商品を含むブログ (50件) を見る もくじ 概要 もくじ SLAとは何か 関係者が同じ目線を持つためのもの 火の一ヶ月間を経て…… SLAは契約ではなく、目標の合意に過ぎない SLA:設計のプラクティス サービスのレベルを設計する 機能観点でのレベル分け コア機能を定義する 非機能観点でのレベル分け オペレーションのレベルを設計する 対応速度のレベル分け 3
■原因について 「max server memory」を指定していない場合、 物理メモリをすべて食い尽くし、SQLServer自体で 利用するメモリが不足するためと考えられる。 SQLServerの仕様のようだが、本番で発生すると痛い。 ■対処法 「max server memory」を設定して下さい。 物理メモリより当然少なくし、OSが利用する分、 SQLServerが利用する分を差し引いた残りを設定する。 トラブル時で時間がないときは、とりあえずサーバ再起動が早道 ■詳細 「max server memory」の既定値は2,147,483,647Mbytes となっている。既定値のままだとどんどんメモリを食う。 消費したメモリは、どこに使われたかというと 「バッファキャッシュ」という所に割り当てられている。 これは、あらかじめディスクから読み込んだデータを メモリ上に展開しておき、次回
どうも!アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。 キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。 では、どうぞ! 障害にすてるところなし サイボウズ株式会社の横田です。 「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。 運用障害の話 まずはじめに、今回のお話をするにあたりまして 運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。 これからも、弊社製品をよろしくお願いいたします。 クラウドの規模と稼働率 障害の話をする前に、サイボウズの
構成管理の最善策 ITIL による構成管理の定義に初めて接した場合、運用スタッフは、通常、肯定的な反応を示します。コンセプトに刺激を受け、プロセスの早急な導入に前向きとなります。しかし、実際に環境の分析に着手し、厳密な制御下で CI に代表される膨大な事象の追跡管理が必要なことがわかってくると、最初の熱意は急速に萎えていきます。そうなると、プロセスが複雑すぎると言って、プロジェクト自体が延期されかねません。すべての CI を個別に記録し、一から追跡しなければならないと見なすなら、それも必然的な結果と言えるでしょう。このような無謀な管理方法は失敗に帰着します。しかし、経験豊富な IT スタッフであれば、落とし穴の存在を知っているので、障害を未然に回避することができます。 これまで、データ センター環境は重厚長大で、複数の所在地にまたがる結果、総体として錯綜した体制に陥りがちでした。なんと言っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く