Changes for page API Gateway Architecture

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Edit memory for on-premise runtime (Linux)
	1	+advanced-solution-architecture-change-memory-runtime-linux

Content

...	...	@@ -1,85 +1,79 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
	2	+This microlearning will focus on the aspects of eMagiz Cloud and sizing of the Cloud
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
	6	+* Last update: October 21st, 2021
8	8	* Required reading time: 5 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 & Deploy architecture aspects
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	+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.
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. eMagiz Cloud sizing ==
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	+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.
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	+=== 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.
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
	25	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-1.png]]
33	33
34		-=== 3.1 Check adviced size ===
	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.
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.
	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 ===
37	37
38		-[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--context-menu-view.png]]
	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.
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.
	39	+=== 3.4 Impact of Cloud sizing ===
41	41
42		-[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--pop-up-details.png]]
	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
43	43
44		-=== 3.2 Edit memory on Linux based runtimes ===
	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
45	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	+This count is also handy when verifying the actual assigned values in Deploy Architecture.
47	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
	49	+=== 3.5 Managing sizing of Event topics ===
60	60
	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:
61	61
	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.
62	62
	56	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-2.png]]
63	63
	58	+
	59	+
	60	+
64	64	== 4. Assignment ==
65	65
66		-As this is a more theoretical microlearning we do not have an assignment
	63	+Please experiment with the options in eMagiz Design architecture to understand the above points.
67	67
	65	+
68	68	== 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.
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
	73	+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
	77	+There is no demonstration video of this functionality.
84	84
85	85	)))((({{toc/}}))){{/container}}{{/container}}