Changes for page API Gateway Architecture

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Consequences of cloud size changes and cloud approval
	1	+Edit memory for on-premise runtime (Linux)

Content

...	...	@@ -1,79 +1,85 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-This microlearning will focus on the aspects of eMagiz Cloud and sizing of the Cloud
3	3
	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	+
4	4	Should you have any questions, please contact academy@emagiz.com.
5	5
6		-* Last update: October 21st, 2021
	7	+* Last update: April 5th, 2022
7	7	* Required reading time: 5 minutes
8	8
9	9	== 1. Prerequisites ==
10		-* Intermediate knowledge of the eMagiz platform
11		-* Good working experience in the Design & Deploy architecture aspects
	11	+* Basic knowledge of the eMagiz platform
12	12
13	13	== 2. Key concepts ==
14		-The eMagiz Cloud is the set of services and machines that make up together the engine in which the integrations are made active. Please refer to the eMagiz Cloud Fundamentals to learn about that Cloud infrastructure.
	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
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
16	16
	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
17	17
18		-== 3. eMagiz Cloud sizing ==
	23	+== 3. Edit memory for on*premise runtime (Linux) ==
19	19
20		-eMagiz provides insight into the required sizing of the machines and runtimes in the Design architecture. Objective is to configure the proper size of the Cloud machines so that the designed architecture can actually be effectuated.
	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.
21	21
22		-=== 3.1 Cloud approval ===
23		-The eMagiz team will provide approval on what type of Cloud your model has access to. In the figure below you can see the first column where the number of machines for a specific T*shirt size are allowed. The Cloud approval can be done by your eMagiz partner and is based on the licensed eMagiz Cloud. Once in the edit modus of the Design architecture, you can assign the available Cloud machine to a specific Core or Connector machine in the architecture.
	27	+The focal point of this microlearning will be to learn how you can safely edit the memory settings for an on*premise runtime.
24	24
25		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-1.png]]
	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
26	26
27		-=== 3.2 Cloud t-shirt sizing ===
28		-eMagiz provides the following sizing for the Cloud slots. The memory is mentioned below as that is the key driver for upgrading to bigger sizing.
	34	+=== 3.1 Check adviced size ===
29	29
30		-1. S size **> 2Gb memory per machine
31		-2. M size **> 4Gb memory per machine
32		-3. L size **> 8Gb memory per machine
33		-4. XL size **> 16Gb memory per machine
34		-
35		-=== 3.3 Cloud sizing advice ===
	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.
36	36
37		-In the [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic.WebHome||target="blank"]] you can see how to the current machines can be reviewed for available memory.
	38	+[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--context-menu-view.png]]
38	38
39		-=== 3.4 Impact of Cloud sizing ===
	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.
40	40
41		-The actual assigned machine size will be implemented in the Deploy architecture. In case your total runtime and machines are consuming more than the available memory of that specific size, the runtimes will not properly load and become disfunctional. To determine overcommitted cloud machines, use the following calculation mechnanism
	42	+[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--pop-up-details.png]]
42	42
43		-1. Count 762 Mb overhead for the machine
44		-2. Count 100 Mb per runtime on the machine
45		-3. Count the tables for the runtime head and non-heap memory according to NL. See this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.expert-solution-architecture-determining-needed-memory.WebHome||target="blank"]] for more information
	44	+=== 3.2 Edit memory on Linux based runtimes ===
46	46
47		-This count is also handy when verifying the actual assigned values in Deploy Architecture.
	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.
48	48
49		-=== 3.5 Managing sizing of Event topics ===
	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
50	50
51		-In the Design architecture you can manage your sizing of Event Streaming topics. eMagiz sees the topics as part of the Cloud infrastructure. Right clicking the topic storage in Design Architecture, would lead to the following screen - see fiugure below. Options available are:
52	52
53		-1. Change sizing values of topics (retention size).
54		-2. Exclude topics * which effectively means that these no longer count towards the configured size and if effectuated in the Deploy will be deleted. This feature is handy to use in the lifecycle of topics from test to acceptance to production. Topics in test can be excluded in case the topic is already in production.
55	55
56		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-2.png]]
57	57
58		-
59		-
60		-
61	61	== 4. Assignment ==
62	62
63		-Please experiment with the options in eMagiz Design architecture to understand the above points.
	66	+As this is a more theoretical microlearning we do not have an assignment
64	64
65		-
66	66	== 5. Key takeaways ==
67		-Part of the eMagiz platform is the Cloud which has specific upper limits for sizing. Understanding these helps to understand the impact of the designed architecture and to decide to influence these upper limits by expanding the sizing to a higher range.
68	68
	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
69	69
70	70
	76	+
71	71	== 6. Suggested Additional Readings ==
72	72
73		-There are no suggested additional readings on this topic
	79	+None
74	74
75	75	== 7. Silent demonstration video ==
76	76
77		-There is no demonstration video of this functionality.
	83	+As this is a more theoretical microlearning we have no video for this
78	78
79	79	)))((({{toc/}}))){{/container}}{{/container}}