[Rakuten TechConf2014] [C-5] Ichiba Architecture on ExaLogic
•Download as PPTX, PDF•
6 likes•4,743 views
Rakuten Technology Conference 2014 "Ichiba Architecture on ExaLogic" Euncheol Kweon, Ryu Watanabe (Rakuten)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to [Rakuten TechConf2014] [C-5] Ichiba Architecture on ExaLogic
Similar to [Rakuten TechConf2014] [C-5] Ichiba Architecture on ExaLogic (20)
More from Rakuten Group, Inc.
More from Rakuten Group, Inc. (20)
Recently uploaded
Recently uploaded (20)
[Rakuten TechConf2014] [C-5] Ichiba Architecture on ExaLogic
- 1. ICHIBA Architecture On Exalogic Oct/25/2014 Euncheol Kweon / Watanabe Ryu EC Core Platform Group ICE Project Team.
- 2. 1 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 3. - Euncheol Kweon 2 About This Presentation 1. Exalogic Architecture 2. Exalogic Operation On OZ Manager - Watanabe Ryu
- 4. 3 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 5. 4 No.1 EC Site in Japan
- 6. 5 No.1 EC Site in Japan
- 7. 6 Biz App Biz API Biz API Biz App Biz App Biz API Biz App
- 8. 7 Business Application Middleware Database Physical Servers Network Service Components Operation
- 9. 8 Many Servers for Service Service A Service B Service C Service D Service E Service F Service G Many Engineers for Operation
- 10. 9 Operational Efficiency Heavy Low Heavy High High Heavy Low Many Engineers for Operation
- 11. 10 0 1 2 3 4 5 6 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 A Service B Service Service Peak Time System Load Time
- 12. If we can use servers more effectively 11 Heavy Low Middle High
- 13. 12 If it can be operated by 4 person.
- 14. 13
- 15. 14 What is Exalogic? Oracle Engineered System Specialized Product for Middleware - WebLogic - Coherence - Tuxedo Total Solution
- 16. 15 Exalogic Elastic Cloud Software Exabus Oracle Traffic Director Storage Management Software Operating System Exalogic Control VM Server Hardware Computer Nodes - Max 30 Nodes Xeon 2.7 8Cores * 2 256 GB Memory 200 GB SSD Integrated Storage - ZFS Storage Appliance 60 TB Storage InfiniBand Switches - 40Gb/s throughput
- 17. 16 Our Plan for Exalogic Japan ICHIBA Over 50 Services About 400Servers Migration Operation Cost Down Non-Stop Operation
- 18. 17 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 19. 18 Exalogic Optional Middleware Structure WebLogic Coherence OTD Jennifer
- 20. 19 OTD (Oracle Traffic Director) OTD Application A:XXX1 Instance 01 : XX.XX.0.1:0000 Instance 02 : XX.XX.0.2:0000 Instance 03 : XX.XX.0.3:0000 Instance 04 : XX.XX.0.4:0000 Application B:XXX2 … Application C:XXX3 … Application D:XXX4 … Application A Instance 01 Instance 02 Instance 03 Instance 04 Application B Application C Application D
- 21. WebLogic Domain Instance 01 Instance 03 Instance 04 Exalogic Optimized Fusion Middleware Installation - 11g 20 WebLogic (Application Server) Business Applications Java - 12c bin config init-info lib pending security servers startWebLogic.sh stopWebLogic.sh tmp Instance 02 - JRockit - HotSpot
- 22. Business Database Logic Session Object Fusion Middleware Installation - 1 2 c 21 Coherence (Data Grid Layer) Coherence Cluster (having DAO) Java - JRockit - HotSpot
- 23. 22 Jennifer (Real Time Monitoring) Application On Middleware Instance 01 Instance 02 Instance 03 Instance 04 Jennifer Server Process Time Method Profiling System Status IO Status VM Status
- 24. 23 System Design On Exalogic
- 25. 24 Design Keywords Automated Standardized Nonstop
- 26. 25 Shared Resources Java Middleware Coherence Cluster WebLogic Domain Configuration Operation Tools Application Logs mount mount 【ZFS】
- 27. 26 Separated Private Resources - bin - config - lib - startWebLogic.sh - stopWebLogic.sh - servers Separated - instance 01/* - instance 02/* - instance 03/* - log - instance 01/* - instance 02/* - instance 03/* Application On Middleware Instance 01 Instance 02 Instance 03 Parameter for Private Resource ${weblogic.Name} ${tangosol.coherence.member} ex) log, data WebLogic Domain Shared
- 28. Rule Based System Configuration 27 App Name App Number Machines IP Zone Exalogic Jennifer WebLogic OTD Coherence Ports Directories Two Parameters for Construction
- 29. WebLogic is Running on Floating IP WebLogic Domain 28 Instance 01 (10.10.1.1) Failed Instance 02 (10.10.1.2) Instance 03 (10.10.1.3) Instance 04 (10.10.1.4) Instance 01 (10.10.1.1) Instance 03 (10.10.1.3) Instance 04 (10.10.1.4) Instance 02 (10.10.1.2) Migrating ManagedServer Shutdown Moving IP Startup
- 30. 29 Standardized Startup Scripts - server_startup Jennifer Ready Remote Control - startServer.sh - scripts - addon.sh - automation.sh - options.sh - properties.sh Process Locking Log & Backup - options.conf Customizing JMX Ready - Coherence Server / CUI Client - WebLogic Admin & Managed Server
- 31. 30 NodeManager and Startup Scripts nodemanager.properties startScriptName=startServer.sh …. …. …. WebLogic Domain NodeManager - server_startup - startServer.sh - scripts - addon.sh - automation.sh - options.sh - properties.sh AdminServer ManagedServer - options.conf ManagedServer
- 33. 32 Main Feature for Nonstop Operation OTD : rakuten.co.jp Listener Listen-Port : 8001 Origin Server Pool 10.10.1.1:7003 10.10.1.2:7003 Origin Server Pool 10.10.2.1:7003 10.10.2.2:7003
- 34. 33 OTD Configuration for Application OTD : rakuten.co.jp 10.10.1.1 : 7003 10.10.1.2 : 7003 Listener default-route : 8001 test-route : 9001 Origin Server Pool 10.10.2.1 : 7003 10.10.2.2 : 7003
- 35. 34 Dual Domains for Application 8001 9001 A Domain ManagedServer Origin Server Pool B 10.10.1.1 : 7003 10.10.1.2 : 7003 B Domain ManagedServer Origin Server Pool A 10.10.2.1 : 7003 10.10.2.2 : 7003
- 36. 35 OTD 1.0 1.1 - Current Service OTD 1.0 1.1 Basic Concept - Next Version Release - Testing via Proxy - Switching - Current Service - 20 Seconds default-route test-route OTD 1.0 0.9
- 37. 36 Operating Time for Service Release 6 Hours 20 Secs
- 38. 37 Sessionful Application A Domain coherence*web B Domain coherence*web Getting Session Data from Coherence Cluster
- 39. 38 Construction Application Package WebLogic Domains Jennifer Servers A B 1~2 Weeks On Legacy Environment
- 40. 39 Application Name Application Number WebLogic Template Construction Automated Tool Jennifer Template END Deploy Service IN
- 41. 40 Construction Application Package WebLogic Domains Jennifer Servers A B 5 Minutes On Exalogic
- 42. 41 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 43. 42 Release Operation Testing Switching
- 44. 43 Release Operation Testing Switching
- 45. Release Material having Same Path Release Material maven-assembly-plugin Service Domain 44 root/domain{A,B} - app/foo-1.0.1.war - configuration/foo.properties - library/lib-0.2.2.jar /root/domain{A,B} - app/foo-1.0.0.war - configuration/foo.properties - library/lib-0.2.1.jar
- 46. 45 Updating New or Modified Resource Recipe for Release Release Material Release History Directory Release Material Latest Release Standby Domain
- 47. 46 Release Work Flow Release Files New Deployment Undeployment Restarting WebLogic
- 48. 47 Switching Operation Release Testing
- 49. OTD Standby Domain 48 Testing Application via Proxy Server intranet Proxy Service Domain
- 50. Problem Solving by Repetitive Testing 49 Updating Application Testing Bug Fix
- 51. 50 Operation Release Switching Testing
- 52. 51 Real Time Service Switching Service Domain Standby Domain
- 53. 52 Creating Operation Directory Operation Directory ${applicationName}/operation/root Release History Directory root.20141025 Release Material renaming link
- 54. 53 Release Testing Switching Operation
- 55. 54 Rollback to Previous Version Release History Directory Release Directory of Previous Version If standby side is updated.. Release Standby Domain Service Domain Switching
- 56. 55 Normal Operation Operation Directory ${applicationName}/operation/root Modifying Configuration Release Service Domain Standby Domain
- 57. 56 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 58. 57 WLST Operation Tools Start / Shutdown Deployment Moving Instance Undeployment Getting Information Modifying Configuration
- 59. 58 Operation Documents Legacy System By System By Material By Time Release Document Release Document Release Document A Reason Of High Operating Cost
- 60. 59 Operation Documents Exalogic Construction Release Switching Operation Recipe Operation Recipe for All Application
- 61. 60 Recipe Execution by Trigger Trigger Recipe Arguments Sequential Execution Automatic Execution
- 63. 62 Introduction Middleware Architecture Life Cycle Cost Effective Operation Exalogic Operation On OZ Manager
- 64. 63 What is OZ Manager ?
- 65. 64 scratchbuild Application Management Tool
- 66. Why scratchbuild ? 65
- 67. 66 because it’s Rakuten Ichiba
- 68. 67 How is Rakuten Ichiba ? Lots of teams Lots of applications Lots of instances Lots of releases
- 69. 68 How is Rakuten Ichiba ? Lots of teams Lots of applications Lots of instances Lots of releases more than 30 teams “team reliant operations” Diff on Rule Diff on Judge Diff on Procedure
- 70. 69 How is Rakuten Ichiba ? Lots of teams Lots of applications Lots of instances Lots of releases more than 150 applications “scattered apps & tools” Diff on Language Diff on Architecture Diff on Monitoring
- 71. 70 How is Rakuten Ichiba ? Lots of teams Lots of applications Lots of instances Lots of releases more than 3000 instances “excessive alert mails” 10,000 mails on trouble receivable only 700 Important mails get buried
- 72. 71 How is Rakuten Ichiba ? Lots of teams Lots of applications Lots of instances Lots of releases more than 1000 releases in a year “more trouble risks” Required to attract Bug occurs Human error happens
- 73. 72 What we needed standardize basic operations integrate and portalize management tools collect log and pack alert mails simplify and clarify for fast detection
- 74. 73 OZ Manager
- 75. 74 OZ Manager 1. Brief Overview 2. Plug-in configuration 3. Data relation 4. Monitoring for Exalogic 5. Demonstration 6. Future plan for Exalogic
- 76. 75 1. Brief Overview OZManager Service Applications Monitoring Tools … Log Collect Tools LogCollector operator
- 77. 76 2. Plug-in configuration plug-in manager Checker Log Collect Application other • Get status • Stop • Start • Update • Get results • Get status • Stop • Start • Update • Get logs • Get status • Stop • Start
- 78. 77 logcollector nagios Exalogic logcollector admin admin qps log perf log basic log pandora nagios 2. Plug-in configuration plug-in manager weblogic Checker Log Collect Application module CPU % chk otdorigin chk perf chk log chk other Exalogic service
- 79. 78 3. Data relation Application Host Component & Control Cluster exalogic rpage rpageA rpageA01 node1 rpageA02 rpageB01 node2 rpageB02 rpageB orderapi rpageA rpage-inst nodeX Controlgroup Filter Checker error applog inst-chk cpu% Link jennifer exalogic
- 80. 79 3. Data Relatoin Authentication & Authorizatoin User Ryu Usergroup admin Menu User Cluster exalogic Mall Kweon-san EC Core Cluster Application Host orderapi rpage userX
- 81. 80 4. Monitoring for Exalogic Type Target Checker CPU usage Load average Filesystem usage Burst process Host - each node Cluster Weblogic service A/B • Application log • Performance log • Alert log Coherence A/B • Application log • Stdout log Application system Oracle EM • Admin server process • Client agent process Nodemanager • Process for each version OTD • Process for each OTD configuration weblogic instances • OTD origin online check coherence instances • Coherence instance check Host Each nodes • Ping check • Cpu usage • Load average • Filesystem usage • Burst process
- 82. 81 5. Demonstration Demo Video Basic Usage
- 83. 82 5. Demonstration Demo Video Maintenance Tool
- 84. 83 5. Demonstration Demo Video Command line Interface
- 85. 84 5. Demonstration Demo Video Exalogic Special Features
- 86. 85 6. Future plan for Exalogic AB service side switch instance location list Instance relocation Exalogic-coherence plugin
- 87. 86 OperationZero
- 88. 87
Editor's Notes
- Good Afternoon! Thank you for attending our session. My name is Kweon. Just call me David. We have introduced Exalogic system on Japan Ichiba in 2013. In This Session, I would like to talk about Ichiba architecture on Exalogic.
- I would like to introduce this presentation. This presentation consists of 5 chapters. It is about the Ichiba Architecture on Exalogic from chapter 1 through 4. And Chapter 5 is about Exalogic Operation on OZ Manager. このプレゼンテーションについて紹介したいと思います。 このプレゼンテーションは５つのChapterで構成されています。 Chapter１から４まではエクサロジック上での市場アーキテクチャーについてです。 そしてChapter５はOZマネジャー上でのエクサロジック運用についてです。
- At first, I will give a presentation about Exalogic Architecture. And Watanabe-san will give a presentation about Exalogic operation on OZ Manager まず、私がエクサロジックアーキテクチャーについてプレゼンテーションします。 そして渡辺さんがOZマネジャー上でのエクサロジックオペーレーションについてプレゼンテーションします。
- So, Let’s start our presentation. The first Chapter is introduction of Exalogic. では、プレゼンテーションを始めましょう。 最初のChapterはエクサロジックの照会です。
- Rakuten Ichiba is No 1 e-commerce web-site in japan. (At least, I think so. w) This is a top page of Japan Ichiba. It seems like a single page. 楽天市場は日本で第1のE－COMMERCEウェブサイトです。（少なくとも私には～～） このページは日本市場のトップページです。 これは一つのページとして見えますが。
- But. Actually, Our Page is consist of many services. しかし 実際には私達のページは多いサービスで構成されています。
- And.. If you can see the back side of our system, you can find that many services are associated with another services completely. そして もし私達のシステムの裏面を見れるとすれば、多いサービスが他のサービスに複雑に関連されていることを確認出来るんでしょう。
- For constructing Service, We have to prepare many components. For Example, We need to construct servers, database, middleware and business application. And, Each Component must connected each other via network. If a service is started, we have to do maintenance for each component. サービスを構築するには私達は色々なコンポーネントを用意する必要があります。 例えば、私達はサーバー、データベース、ミドルウェアー、そしてビジネスアプリケーションを構築する必要があります。 そして、各コンポーネントはネットワークで繋がってないといけない。 サービスが開始されると私達は各コンポーネントにメインテナンスをしないと行けない。
- Most of Service Companies are maintaining massive systems for providing many services. And, Many Engineers will be needed for operating our massive system. 殆どのサービス会社は多いサービスを提供するため、大規模システムを維持しています。 そして、多いエンジニアが大規模システムを稼働するために必要になります。
- Everything was prepared perfectly. But, Sometimes, We notice that Systems can't be operated effective. 全て完璧に用意されている。 しかし 時には私達はシステムが効率的に運用されてないことに気づく。
- That Reason is that Most of services have different peak time. In Same time, Both low load service and high load service are existing. but, High load service can't use resource of low load service because Each Service is using different system. その理由は殆どのサービスが異なるピークタイムを持っているからです。 同じ時間に低負荷サービスと高負荷サービスが存在する。 しかし、高負荷サービスは低負荷サービスのリソースを使えない。なぜなら各サービスは異なるシステムを使っているから。。
- If we can use the servers more effectively.. もし、私達がサーバーをもっと効率的に使えば～
- And If system can be operated by 4 or 5 person, it will be great thing. そして、それが４，５人で運用出来れば、それは素晴らしいことでしょう。
- So, We have decided to introduce the Exalogic System on Japan Ichiba. それで、私達は日本市場にエクサロジックを導入すると決めました。
- Exalogic is the Engineered System manufactured by Oracle. And, It is customized for Fusion Middleware such as WebLogic and Coherence. エクサロジックはオラクルが製造したエンジニアドシステムです。 そしてエクサロジックはウェブロジックとコヒーレンスのようなFusionミドルウェア―にカスタマイズされています。
- This is the specification of Exalogic. As you know, Exalogic is very powerful system. And, Exalogic is including Operation System ,Managing Software and Oracle Traffic Director. Oracle Traffic Director is very important software for Japan Ichiba. Please! Remember OTD. I will explain about OTD later. これはエクサロジックの仕様です。 ご存知のようにエクサロジックは非常にパワープルなシステムです。 そして、エクサロジックはOS、管理ソフトウェアー、OTDを含んでいます。 OTDは日本市場に置いて非常に重要なソフトウェアーです。 OTDを覚えておいてください。後でOTDについて説明します。
- Anyway, Our Plan is to migrate Japan Ichiba from legacy system to Exalogic. Our Target Services are about 50 services, and operated by 400 servers. we are expecting to down operating cost and realize nonstop system by introducing Exalogic. とにかく、私達の計画は日本市場の４００台、５０サービスをエクサロジックに移行することです。（？？？？？？？？） 私達はエクサロジックを導入することでオペレーションコストを下げて、ノンストップシステムを実現しようとしています。
- The second Chapter is about middleware architecture on Exalogic. 2番目のCHAPTERはエクサロジック上のミドルウェア―アーキテクチャーについてです。
- Oracle Traffic Director is located on front side for forwarding requests to application servers such as WebLogic. As everyone know, WebLogic Server is used as a Web Application Server. Actually, Requests will be processed at WebLogic server. Optionally, Coherence can be located between WebLogic and Database. Coherence will be used to cache server for business object or session data. Also, All the servers will use Jennifer Server for real time monitoring. If you don’t know Jennifer, Don’t worry. I will explain it later. OTDはリクエストをウェブロジックのようなアプリケーションサーバに転送するために前端に位置します。 ご存知のようにウェブロジックサーバはウェブアプリケーションサーバーとして使われます。 実際にリクエストはウェブロジックで処理されます。 付加的にコヒーレンスはウェブロジック及びデータベースの間に位置付けられます。 コヒーレンスはビジネスデータ及びセッションデータのキャッシュサーバーとして利用されます。 また、全てのサーバーはリアルタイムモニタリングのため、ジェニファーサーバーを利用します。
- OTD is a load balancer software. OTD has access information to each service. All Requests on Exalogic are only processed via OTD. OTDはロードバランサーソフトウェアーです。 OTDは各サービスへのアクセス情報を持っています。 エクサロジック上の全てのリクエストはOTDを経由してのみ、処理されます。
- WebLogic Server is a part of Fusion Middleware software. Our Applications will be deployed on WebLogic Server. We are supporting 11g and 12c for Exalogic. ウェブロジックサーバーはフュジョンミドルウェア―ソフトウェアーの一つです。 私達のアプリケーションはウェブロジックサーバー上にデプロイされます。 私達はエクサロジックのために１１ｇと１２ｃを支援しています。
- Coherence is a java based data grid software supporting in-memory access. Usually, Coherence Server has Data Access Objects. And, Stored Objects in Coherence can be updated to database later. This function is called Write-behind. If we use write behind function of coherence, We can improve our application performance dramatically. And, We are supporting 12c for coherence on Exalogic. コヒーレンスはインメモリアクセスを支援するデータグリッドソフトウェアーです。 普通はコヒーレンスはDAOを持っています。 そして、コヒーレンスに保存されたオブジェクトは後でデータベースにアップデート出来ます。 この機能をWrite-Behindと言います。 コヒーレンスのWrite-Behind機能を使えば、もっと早いアプリケーションを実現出来ます。 私達はコヒーレンスについては１１ｇと１２ｃを支援しています。
- Jennifer is the real time monitoring system introduced to Japan Ichiba in 2012. This is the dashboard of Jennifer Server. If the Jennifer server is connected to the application server, We can always monitor all processed requests on all servers. ジェニファーは２０１２年、楽天に導入されたリアルタイムモニタリングシステムです。 私達はジェニファーサーバーを使って全ての処理されるリクエストを監視出来ます。
- From next slide, I will explain about system design on Exalogic. 次のスライドからエクサロジック上のシステムデザインについて説明します。
- We have considered 3 keywords while designing system architecture on Exalogic. Those are automated, standardized and nonstop. Ichiba’s system scale are expected to grow in a future. And our goal is to have this big system manageable by 4 or 5 person. Automate and standardize are essential requirements to reduce operation. And at the same time we have to guarantee the nonstop system. All of system designs on Exalogic are based on this 3 keywords.
- Exalogic System is providing a zfs appliance of 60 terabyte. So, We have decided to use zfs storage for every applications and data storing. We have created two shares for application and data. And we have mounted shares to every computer node. If we need additional computer node, we can start instance on additional node by mounting shares. Because, All of Installation, data and operation tools are existing on shares. We are using the Infini-band network for communication between computer node and zfs appliance. It is very fast like a local disk. エクサロジックは６０TBのZFSアプライアンスを提供しています。 それで、我々は全てのアプリケーションのデータ保存にZFSストレージを使うことにしました。 我々はデータ用とアプリケーション用のシェアを２つ生成し、全てのコンピュータノードにマウントしました。 もし、追加ノードが必要になれば、我々は追加ノードにシェアをマウントするだけでインスタンスを起動出来ます。 なぜなら、全てのインスト―レーション、データ、及び運用ツールがシェアにあるからです。 我々はコンピュータノードとZFSアプライアンスの間の通信にInfini-Bandネットワークを使っていてローカルディスクのように非常に早いです。
- All of Servers are sharing resource such as Middleware installation, domain installation, library and configuration. And, Servers also needs private resource such as log files, application data, and managing data for each instances. These resources need to have separate path. If resources are not separated, It will be the bottleneck. We are using variables having instance name to separate resources. 全てのサーバはミドルウェアインストールレーション、ドメインインスト―レーション、ライブラリ、そして設定などのリソースを共有しています。 そして、サーバは共有リソース以外にも個別なリソースが必要です。 それはログファイル、アプリケーション、各インスタンスの管理データなどがあります。 このリソースはアクセスパスを分離する必要があります。もし、分離しなければそれはボトルネックになります。 そして、我々はリソースを分離するためにWebLogic.Nameとtangosol.coherence.member変数を利用しています。
- And We must control not to duplicate server resource such as port number and IP address. Because Exalogic is sharing a server resource for all applications. So, We had designed rule based application for using not duplicated resource. We have created operation tool for auto construction. And, If we want to construct application, we need to decide only two parameters. It’s a application name and number as a indicator for application. If our construction tool knows only two parameters, Application will be constructed automatically. そして、我々はポート番号やIPアドレスのようなサーバリソースを重複しないように制御しないと行けません。 なぜなら、エクサロジックは全てのアプリケーションに対してサーバリソースを共有するからです。 それで、我々はリソースが重複しないようにルールベースのアプリケーションを設計しました。 我々は自動構築用のオペーレーションツールを作成しました。 そして、アプリケーションを構築したいなら、２つのパラメータを決める必要があります。 それはアプリケーション名とアプリケーションを認識するための番号です。 構築ツールがこの２つのパラメータを知っていれば、アプリケーションは自動的に構築されます。
- One of our most Important things is a floating IP for operating application server on Exalogic. Each WebLogic Domain is using different floating IP Zone. And Floating IP Address for Managed Server is predefined on config.xml of WebLogic Domain. Floating IP Address can be moved to the another computer node by online. As a Result, If managed Server has a problem, we can simply migrate managed Server to another computer node. And, We can migrate managed Server by one command in 2~ 3 minutes. エクサロジック上でアプリケーションを運用する際に一番重要なことの一つはFloating IPです。 各ウェブロジックドメインは別のFloating IPゾンを使っていて、管理対象サーバのFloating IPアドレスはウェブロジックドメインのCONFIG.XMLに定義されています。 Floating IPアドレスはオンライン上で別のノードに移行出来ます。 結果的に管理対象サーバに問題が起きたら、我々は簡単に管理対象サーバを別のノードに移動出来ます。 そして我々は２～３分内にコマンド一つだけで管理対象サーバを移設出来ます。
- Legacy Applications had one problem. Most of Legacy Applications have the different execution environment. Many applications are using different middleware version, environment variables and customized script. So, We need the education cost for learning legacy applications. Accordingly, We feel the need to standardizing environment. So, We created the standardized script set for all applications running on Exalogic. This Script Set can control WebLogic and Coherence Server remotely. And, When jennifer server is installed, It is designed to start Monitoring automatically. Also, We did prepare a option configuration file for customizing application. As a result, our applications have same script set except option configuration file. And We can control all application servers remotely by using same command. 既存アプリケーションは一つ問題がありました。 殆どの既存アプリケーションは異なる実行環境を持っていました。 多いアプリケーションが異なるミドルウェアバージョン、環境変数、カスタム化されたスクリプトを使っていました。 それで、我々は既存アプリケーションを習うために教育コストが必要だったんです。 その理由で我々は環境を標準化する必要があると思いました。 それで、我々はエクサロジックで動かす全てのアプリケーションで使うために標準化されたスクリプトセットを作りました。 このスクリプトセットはウェブロジックとコヒーレンスサーバーをリモートでコントロール出来ます。 そして、ジェニファーサーバがインストールされていれば、自動的にモニターリングが始まるように設計しました。 また、我々はアプリケーションをカスタマイズするため、オプション設定ファイルを用意しました。 結果的にはアプリケーションはオプションファイル以外は全て同じスクリプトセットを持つことになりました。 そして、我々は全てのアプリケーションをリモートで同じコマンドを使って制御出来るようになりました。
- But, As everyone knows, NodeManager is used to control WebLogic Servers remotely. If WebLogic Instance is started by NodeManager, standardized script set will not be used. But, We know that the NodeManager can be customized by editing nodemanager.properties. We have combined NodeManager with Our Script Set. So, We can use anything to control WebLogic Server. WebLogic will be maintained same environment. しかし、皆さんも分かっていると思いますが、ノードマネジャーもウェブロジックサーバーをリモートで制御するために使われます。 もし、ウェブロジックインスタンスがノードマネジャーによって起動されると標準化スクリプトは使用去れないでしょう。 しかし、我々はノードマネジャープロパティーを使ってノードマネジャーをカスタム化出来ると知っていました。 我々はノードマネジャーとスクリプトセットを結合しました。 そして、我々はどれもウェブロジックサーバの制御に使えるようになりましたし、同じ環境を維持されるようになりました。
- Our Main focus is construction non-stop system Until Now, Our Legacy System is used to stop when doing system maintenance. The most important thing is to remove downtime. 私達のメインフォーカスはノンストップシステムを構築することです。 今まで、我々の既存システムはシステムメインテナンス時に止まる場合がありました。 何よりも重要なのはダウンタイムを無くすることです。
- We need to know some function of OTD to make non-stop system happen. For processing request, OTD needs configuration having port number and application server information. Port number is called Listener. And, application server information is called ORIGIN-SERVER-POOL. and OTD will forward requests to application server based on configuration. For Each Service, We need to associate access port number and application servers. And, listener’s origin-server-pool can be changed dynamically. ノンストップシステムを実現するにはOTDのある機能を知る必要があります。 リクエストを処理するため、OTDはポート番号とアプリケーションサーバー情報が必要です。 ポート番号はリスナーと言います。そして、アプリケーションサーバ情報をORIGIN－SERVER-POOLと言います。 そして、OTDは設定を元にアプリケーションサーバーへリクエストを転送します。 各サービスのため、私達はポート番号とアプリケーションサーバーを関連付ける必要があります。 そして、リスナーのORIGIN_SERVER_POOLは動的に変更出来ます。
- So, We have defined two listeners and origin-server-pool on OTD for each service. それで私達はサービス毎に２つずつ、リスナーとオリジンサーバープールをOTD上に定義しました。
- And, We have constructed two WebLogic domains for a application in order to connect origin-server-pool. As a result, Listener can connect to the A or B domain by switching origin-server-pool. そして、私達はオリジンサーバープールに繋ぐためにアプリケーション毎に２つのウェブロジックドメインを構築しました。 結果的に、ポートはAドメインとBドメインを切り替えるようになりました。
- Now, We can release and test to the application at the test domain in advance. And, We can make nonstop maintenance possible by switching origin-server-pool of listener. The good point is that we can test the application on production environment before service release When we decided to introduce this design, We didn't know that the concept already exist. It is called the blue green deployment. これで、私達は事前にテストドメインにアプリケーションをリリースしてテスト出来ます。 そして、リスナーのオリジンサーバープールをスウィチして無停止メインテナンスを実現出来ます。 良い点はサービスリリース前に本番環境でアプリケーションのテストが出来ることです。 私達がこのデザインを導入すると決めた時には私達はこの概念が既にあるとは知りませんでした。 これはブルグリーンデプロイメントと言います。
- The Effect of using blue-green deployment was very successful. In case of our first migrated application, which was in April, 2014. Release time was reduced from 6 hours to 20 seconds. 実際に最初に移行したアプリケーションの場合、既存システムでサービスリリースに約６時間程度、時間が必要だったが、 エクサロジック上では20秒になりました。
- But.. If our application is sessionful, Session Data will be lost when switching application. For resolving the problem, We constructed coherence cluster including two weblogic domains. Session Data will be stored in coherence cluster. And WebLogic Domain can access the session data by using coherence web. We can solve the problem by sharing session data to the coherence cluster. しかし アプリケーションがセッションプルならば、アプリケーションスウィチ時にセッションデータが消えてしまいます。 この解決のため、私達は両ドメインを含んでいるコヒーレンスクラスターを構築しました。 セッションデータはコヒーレンスクラスターに保存されます。そしてウェブロジックドメインはコヒーレンスウェブを使ってセッションデータへアクセス出来ます。 私たちはコヒーレンスクラスターにセッションデータを共有することでこの問題を解決出来ました。
- Now we know, to make nonstop operation possible, application needs two Domains. And also, We know that Jennifer server is necessary to monitor Weblogic Domains. Which means that we need 4 installation to construct service. For Legacy environment, we needed 1 or 2 weeks for construction. 今、私達はノンストップオペレーションを実現するためには２つのウェブロジックドメインが必要だと知っています。 また、ウェブロジックドメインをモニタリングするジェニファーも必要だと知っています。 それはアプリケーションを構築するには4回のインストールが必要だという意味です。 もし、既存環境だったら、私たちはアプリケーション構築に１～２週間必要だった。
- We wanted to cut construction time on Exalogic. so, we have created a tool for automatic construction. A Tool is constructing application by using Templates. and Required Information is only application name and number for construction. 私たちはエクサロジック上での構築時間を短縮したいと思っていました。 それで私達は自動構築用のマニュアルを作成しました。 マニュアルはテンプレートを使ってアプリケーションを構築します。そして、構築に必要な情報はアプリケーション名と番号のみです。
- Now by automating, we only need 5 minutes to construct service. アプリケーションを構築したい場合、マニュアルを使って5分以内に作成されるようになりました。
- I have explained the concept of System Design on Exalogic. Next Chapter is an application life cycle on Exalogic. Exalogic上のシステムデザイン概念を説明しました。 次のChapterはエクサロジック上でのアプリケーションライフサイクルです。
- All applications on Exalogic have Same Lifecycle. A Lifecycle has 4 phases. Release, Testing, Switching and Operation. エクサロジック上の全アプリケーションは同じライフサイクルを持っています。 ライフサイクルは４段階である。リリース、テスト、スウィッチ、そしてオペレーション
- First Phase is an Application Release. 最初のステップはアプリケーションリリースです。
- A Rule for application release is that release material has to keep same directory structure with production environment. We can release any application by keeping this rule. If you use maven, I would like to recommend assembly-plugin. When building application, Maven's assembly-plugin can deploy files to predefined directory. アプリケーションリリースのルールはリリース物は本番環境と同じディレクトリを持たないと行けないことです。 このルールを守ることによって私達はどんなアプリケーションもリリース出来ます。 もし、MAVENを使っているなら、私はAssembly-pluginをお勧めします。 アプリケーションをビルドする時にMAVENのAssembly-pluginはファイルを任意のディレクトリに配置出来ます。
- After preparing release material, It will be moved to Release history Directory. And We can release files to standby domain. Release Task is executed by release recipe automatically. And Only New or Modified resources can be updated. Recipe is a executable release document. I will explain it at chapter 4. リリース物が用意されると、それはリリース履歴ディレクトリに移動されます。 そして私達はStandbyドメインにファイルをリリース出来ます。 リリースタスクはStandbyReleaseマニュアルを使って自動的に実行されます。そしてリリースタスクは新規または更新されたリソースのみ、更新出来ます。
- This is the workflow of release recipe. If application is already installed, We are always removing old application. and After restarting WebLogic domain, Updated Application will be installed on WebLogic Domain of clean status. これはリリースマニュアルのワークフローです。 既にアプリケーションがインストールされていれば、私達は何時も古いアプリケーソンを削除しています。 そして、ウェブロジックドメインを再起動した後、新バージョンのアプリケーションは綺麗な状態のウェブロジックドメインにインストールされます。
- Next Phase is Testing. 次のフェーズはテストです。
- I have explained that we can access standby domain via listener for test If application has been released, we can always access to application from internal. 私はテストリスナーを経由してスタンドバイドメインにアクセス出来ると説明しました。 アプリケーションがリリースされていれば、私達は何時でも内部からアプリケーションにアクセス出来ます。
- It is the big benefit to test application in production before service-in In Test phase, Application can be updated many times over. So, We can fix the problem of application before switching application. 事前にアプリケーションをテスト出来るのはよいメリットです。 テスト段階ではアプリケーションは何度も更新出来ます。 そして、私達はアプリケーションスウィチング前にアプリケーションの問題を解決出来ます。
- If the test is finished, Upgraded service can start by switching application. テストが完了すれば、アプリケーションをスウィッチし、最新サービスを開始出来ます。
- Service can be switched without stopping. This Video was recorded during domain switch. If you watch the video, you will be able to understand the concept of switching. Movie on top is the Dashboard of current service domain. And bottom Movie is the standby domain. If we switch domain, All requests will be moved to standby domain. After switching, standby domain will be new service domain. And Old Service domain will be standby domain. サービスはリアルタイムで切替出来ます。 このビデオはアプリケーションスウィチングの記録です。 このビデオを見れば、スウィチングの概念が分かるようになるのでしょう。
- After switching an application, Release Material needs to be renamed to the name including switched date. And, This Directory will be linked to directory for operation. release material and production environment will directed same point. And Linked Directory will be used for operation of the production environment. アプリケーションをスウィチングした後、リリース物は切替日を含んだ名称にリネームする必要があります。 そして、そのディレクトリはオペーレーション用のディレクトリにリンクされます。 リリース物と本番環境は同じであり、 リンクされたディレクトリは本番環境のオペーレーションのために使われます。
- Now, We need to operate the production application. これからは私達は本番アプリケーションを運用する必要があります。
- When the Application raises some problem, It needs to rollback previous version. If standby domain is not updated, It will be returned to previous version by switching application. In this case, We can change application in just a few seconds by using automated recipe. But, If the application is already updated, we need to deploy the application of previous version to standby domain. For this situation, we are storing release history. We can deploy application to standby domain by using release material of previous version. As a result, We can switch to the previous application in 5 minutes by one command. Service don't stop in any cases. アプリケーションが問題を起こした場合、前のバージョンに戻す必要があります。 スタンドバイドメインがまだ更新されてなければ、アプリケーションをスウィチするためで前のバージョンに戻ります。 この場合、私達は自動化されたマニュアルを利用し、数秒以内で切り替えが出来ます。 しかし、アプリケーションが既に更新された場合には私達はスタンドバイドメインに前のバージョンのアプリケーションをデプロイする必要があります。 この状況のため、私達はリリース履歴を保管している。 私達は前バージョンのリリース物を使ってスタンドバイドメインにアプリケーションをデプロイ出来ます。 結果的に私達はコマンド一つで5分内に前のアプリケーションに切替出来ます。 どの場合にもサービスは止まらない。
- Normal Operation means to update configuration of production application in real time. For normal operation, We are using released material existing in the operation directory. At first, We will update configuration file of released material. And The Configuration Files will be updated from operation directory to production application. So, The Operation Directory is always maintaining the latest status. 通常運用はリアルタイムで本番アプリケーションの設定を更新することを意味します。 通常運用のため、私達はオペーレーションディレクトリにあるリリースされた物を使用しています。 まず、私達はリリースされた物の設定ファイルを更新します。 そして、 設定ファイルはオペーレーションディレクトリから本番アプリケーションへ更新されます。 それで、オペーレーションディレクトリは常に最新状態を維持しています。
- My last chapter is about cost effective operation. 最後
- WLST is command based tools for WebLogic. We are using WLST commands for controlling WebLogic Domain on Exalogic. It's a good solution for automated operation. because of, The operation recipe can use WLST commands. WLSTはウェブロジック用のコマンドベースツールです。 私達はエクサロジック上のウェブロジックドメインを制御するのにWLSTコマンドを利用しています。 オペーレーションマニュアルはWLSTコマンドを使えるので自動化されたオペーレーションには良い対策です。
- Release Document is a list of os commands for release operation. . For the legacy system, we are doing release operation by cutting & pasting commands from release document manually. And for every maintenance we have to update release document. because Most of Applications have different environment. It was a reason of high operating cost. レガシシステムを運用する時には、私達は全てのメインテナンスにリリースマニュアルを作成しました。 なぜなら、殆どのアプリケーションが異なる環境を持っていたからです。 それは高い運用コストの原因になりました。
- But For Applications on Exalogic, operations are standardized and can be covered by one release document. We are calling it “operation recipe”. Most of Exalogic Operations are done by these Recipes. And, We are using only three operation recipes. Construction, Release, and Switching. しかし エクサロジック上のアプリケーションは標準化されているので、私達は一つのマニュアルで全サービスをカバー出来ます。 殆どのエクサロジックオペーレーションはマニュアルで実行されています。 そして、私達は運用マニュアルを３つしか使っていません。
- For more effective operation, We made trigger system. Trigger System is auto execution tool for operation recipe. Trigger System can select mode whether sequential and automatic execution. And We can register trigger as a job of jenkins. In this Case, We can execute operating task on web browser. もっと効果的なオペーレーションのため、私達はトリガーシステムを作りました。 トリガーシステムはリリースマニュアルの自動実行ツールです。 トリガーシステムは順番に実行するか、自動的に事項するかモードを選択出来ます。 そして、私達はトリガーをジェンキンスのジョブとして登録出来ます。 この場合、私達はウェブブラウザーで運用タスクを実行出来ます。
- This is a demo video creating application using Trigger. In this demo, We are creating two WebLogic Domains and two Jennifer servers. To create application, We have to input some arguments. Those are application name, number, WebLogic version, and our construction recipe. <click> Then, Our recipe will start creating application. WebLogic and Jennifer servers will be created by using template. As you see, After Installing Servers, recipe is using wlst command and shell commands to update server configuration. And All configuration steps are printed in console. For Jennifer, we needs many ports for monitoring. We have to make sure not to conflict ports for all servers. And It is done automatically by our recipe. By using this trigger system, We reduced operating time extremely This Demo is played in 8x speed. So actually, it is taking about 5minutes. When our construction recipe is finished, Our Server is already started. So, If we have release material, we can deploy application right away. このデモはトリガーを使用してアプリケーションを構築する映像です。 このデモでは２つのウェブロジックドメインと2つのジェニファーサーバを構築しています。 トリガーシステムを使うことによって私達は運用時間を極端的に減らすことができました。
- Next Chapter is about Exalogic Operation on OZ Manager. Watanabe-san will give a presentation.