Changes for page API Gateway Architecture

Last modified by Erik Bakker on 2024/09/02 16:04

From version 6.1
edited by Erik Bakker
on 2022/06/13 08:18
Change comment: There is no comment for this version
To version 1.2
edited by Erik Bakker
on 2022/06/13 08:05
Change comment: Update document after refactoring.

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Edit memory for on-premise runtime (Linux)
1 +advanced-solution-architecture-consequence-size-cloud
Content
... ... @@ -1,85 +1,58 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 +This microlearning will focus on some considerations for putting the eMagiz runtime at the right location in the architecture.
2 2  
3 -Sometimes you have runtimes running on*premises. What we mean by that is that the runtimes are running within a data center of the customer instead of running in the eMagiz Cloud. For running a runtime on*premise we support running them on either Windows or Linux as the operating system. In this microlearning, we will learn how you can edit the memory settings of a runtime that is deployed on*premise on Linux.
4 -
5 5  Should you have any questions, please contact academy@emagiz.com.
6 6  
7 -* Last update: April 5th, 2022
8 -* Required reading time: 5 minutes
6 +* Last update: October 20th, 2021
7 +* Required reading time: 10 minutes
9 9  
10 10  == 1. Prerequisites ==
11 -* Basic knowledge of the eMagiz platform
10 +* Intermediate knowledge of the eMagiz platform
11 +* Good working experience in the Design and Deploy Architecture phase.
12 12  
13 13  == 2. Key concepts ==
14 -This microlearning centers on editing the memory settings for an on*premise runtime that is running on Linux. With an on*premise runtime we mean: A runtime that is running within a data center of the customer instead of running in the eMagiz Cloud
14 +In the various microlearnings until the intermediate level, we have explained the eMagiz runtime (https://emagiz.github.io/docs/microlearning/crashcourse*platform*deploy*install*local*connector). In short, it is the process that can make the flow components operational and execute the designated tasks of that flow. Please refer to these microlearnings for further information
15 15  
16 -The focal point of this microlearning will be to learn how you can safely edit the memory settings for an on*premise runtime running on Linux
17 17  
18 -* The key aspects are:
19 - ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
20 - ** You need access to the on*premise location to perform the action
21 - ** Only change the wrapper.conf file. Nothing else
22 22  
23 -== 3. Edit memory for on*premise runtime (Linux) ==
18 +== 3. Specific eMagiz runtime considerations ==
24 24  
25 -Sometimes you have runtimes running on*premises. What we mean by that is that the runtimes are running within a data center of the customer instead of running in the eMagiz Cloud. For running a runtime on*premise we support running them on either Windows or Linux as the operating system. In this microlearning, we will learn how you can edit the memory settings of a runtime that is deployed on*premise.
20 +=== 3.1 Messaging pattern runtimes ===
26 26  
27 -The focal point of this microlearning will be to learn how you can safely edit the memory settings for an on*premise runtime.
22 +For Messaging specific patterns the runtime should be placed in such a way that there is connectivity between that runtime and the sending/receiving system. The system might be located in a Cloud service or Cloud VPC that eMagiz clients are hosting. Or are located on*premises of the client. Here are the options and advice for putting the runtime.
28 28  
29 -* The key aspects are:
30 - ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
31 - ** You need access to the on*premise location to perform the action
32 - ** Only change the wrapper.conf file. Nothing else
24 +1. Sender or Receiver system is located in a public or private Cloud
25 + * Put the Runtime on a Cloud Connector machine and ensure to use the connectivity options provided in eMagiz
26 +
27 +2. Sender or Receiver system is located in a DMZ section of the client infrastructure
28 + * Put the runtime inside the same DMZ zone to keep the runtime as close to the system as possible
29 + * Ensure the management of the runtime is something workable for the client. Consider the updates that may occur as well as the fact that the runtime can no longer be managed by the eMagiz Portal
30 +
31 +=== 3.2 API Gateway pattern runtimes ===
33 33  
34 -=== 3.1 Check adviced size ===
33 +For these runtime the first choice is put all the Gateway Entry Flow and the Exit gates on the Cloud Connector machine. This way, the number of runtimes are kept to a minimum and there is full control over these runtime. In the exceptional case where the exit gate needs to connect to a system that is not accessible via the client firewalls, you can opt to put these exit gates only on a runtime that can be deployed on*premises. Please refer to the [microlearning around running part of the solution locally](advanced*api*management*running*part*of*your*api*gateway*solution*on*premise)
35 35  
36 -Within Design Architecture you can see for each connector runtime what the advised sizing of eMagiz is based on how you have configured your integration data model. To do so navigate to Design *> Architecture and open the context menu on connector runtime level via a right mouse click.
35 +=== 3.3 Event Streaming pattern runtimes ===
36 +In the case where Event processors are used in the Event Streaming solution designed, eMagiz provides a event streaming container (runtime). This runtime can only run in a Cloud-based machine, and only in the core machines of eMagiz. The key reason is that these Event Processors need to connect to the topics that are only available in the eMagiz Cloud and not accessible from outside the eMagiz VPC. Any runtime that is consuming or producing data with these topics needs to have the capability to access such topics.
37 37  
38 -[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--context-menu-view.png]]
39 39  
40 -When selecting the option View container a pop*up will be shown. Within this pop*up, you will see the advised heap and non*heap memory settings of that particular runtime.
41 41  
42 -[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--pop-up-details.png]]
43 43  
44 -=== 3.2 Edit memory on Linux based runtimes ===
45 -
46 -Now that we know what the advised size is we can navigate to our on*premise installation location to edit the memory settings. Below we will detail the various steps needed to make this happen.
47 -
48 -* Log in via Putty by typing in the host and the port and press load
49 -* When asked for credentials fill in credentials (Be aware, Linux does not acceapt ctrl+v and does not show the password or an indication of the password). Right mouse click to copy the password and press enter
50 -* Navigate to the directory where you have installed the runtime (Command is: cd {directory structure})
51 -* Open the folder related to the runtime you want to change (Command is: cd emagiz_{technicalbusname}-{containertype}-{techincalnameruntime}_{environment}).
52 -* Open the etc folder within your runtime installation (Command is: cd etc)
53 -* Type in the following command: sudo vi emagiz and press Tab. This way Linux should auto suggest the so called wrapper.conf to be edited and press Enter if so
54 -* Type "i" to enter insert mode
55 -* Change the values of heap and or metaspace memory you want to change (you can navigate through the document with your arrow keys)
56 -* Press ESC and then type ":wq!" then press Enter to save the changes and exit Edit mode. Note: If you would like to exit the file without making any changes press ESC, then type ":q!" and press Enter
57 -* Restart the runtime by executing the correct restart command:
58 - ** systemd type: sudo systemctl restart <SERVICE_NAME>
59 - ** SystemV Type: sudo /etc/init.d/<SERVICE_NAME>-service restart
60 -
61 -
62 -
63 -
64 64  == 4. Assignment ==
65 65  
66 -As this is a more theoretical microlearning we do not have an assignment
43 +There is no specific assignment as this is more theoretical microlearning.
67 67  
68 68  == 5. Key takeaways ==
46 +Take into account the key considerations for each case to ensure the runtime is placed on the right location.
69 69  
70 -* The key aspects are:
71 - ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
72 - ** You need access to the on*premise location to perform the action
73 - ** Only change the wrapper.conf file. Nothing else
74 74  
75 75  
76 -
77 77  == 6. Suggested Additional Readings ==
78 78  
79 -None
52 +There are no suggested additional readings on this topic
80 80  
81 81  == 7. Silent demonstration video ==
82 82  
83 -As this is a more theoretical microlearning we have no video for this
56 +There is no demonstration video of this functionality.
84 84  
85 85  )))((({{toc/}}))){{/container}}{{/container}}