So, you want (or need) to become a SAS Viya platform administrator?  Even if you have been a SAS 9 or SAS Viya 3.5 administrator, grasping the differences between the new SAS Viya platform running on Kubernetes and previous versions of SAS software presents a daunting challenge for almost everyone.   With so much to learn, where should you begin?   SAS' new learn.sas.com portal has a free SAS Viya Administration: Getting Started offering that provides an easy-to-follow plan for learning about the key concepts a SAS Viya administrator needs to know.  If you commit to spending a little bit of time each day for three weeks, you can easily finish the material we have collected together from many sources such as SAS Communities articles, YouTube videos, and selected sections of SAS workshops.   At the end of the three weeks, you will have a sound introduction to many of the core concepts a SAS Viya administrator needs to know, and we offer you advice on how to continue your learning journey.   Begin your journey...   All you need to get started is a free SAS profile. Armed with that, you can visit SAS Viya Administration: Getting Started to begin your journey.   Select any image to see a larger version. Mobile users: If you do not see this image, scroll to the bottom of the page and select the "Full" version of this post.   The plan...   Your mission is to spend a little bit of time each day on a variety of topics.  The good news is that you do not have to complete every single topic to progress.  If you are already familiar with a concept just skip it and move along to something else.  Pick and choose, skip around, the path you follow is completely up to you.   If you are totally new to the SAS Viya platform, you may find it helpful to follow the plan from start to finish.  There are time estimates for each item so you can budget your time in a way that best suits your schedule.   Days 1 - 5   During the first five days, you'll look at who is involved in administering a SAS Viya platform deployment, get an overview of the deployment and configuration process, and learn about managing users and groups.     Days 6 - 15   The next few days will be spent looking at topics on security, managing the various SAS Viya platform services, performing backups and updates, and a special look at managing the Cloud Analytics Service (CAS) servers and the SAS Programming Run-time servers.     Days 16 - 21   You will then finish up with a look at observability topics like monitoring and logging, troubleshooting techniques, and how to integrate the SAS Viya platform with third-party applications such as remote data sources and cloud storage.     Continue your journey...   Will this collection of material teach you everything you need to know about being a SAS Viya administrator?   No, it won't. Our intent is to introduce you to many of the key skills you will need to develop over time.  You may even discover that you know more about SAS Viya administration than you thought you would. In that case, you can use SAS Viya Administration: Getting Started as a roadmap for developing your skills in areas you find particularly challenging.   At the end of the material, you will find links to additional resources you can use to further your knowledge such as   The SAS Administration Learning Subscription which provides you with access to the entire SAS Administration training catalog SAS Mentoring Services for meeting privately with SAS administration specialists Live Web Class Schedule for viewing upcoming live web training sessions.   Good luck on your journey to become a SAS Viya platform administrator!   Find more articles from SAS Global Enablement and Learning here. ... View more

In earlier articles on integrating the SAS Viya platform with Python and R I mentioned that it was possible to define additional profiles that would allow programmers the flexibility to use different versions or configurations of open-source software. Based on questions that I have had recently, there is interest in knowing exactly how to define additional profiles - especially after people watch Sundaresh Sankaran's Python à la carte: Configure repeatable & reusable Python environments video on YouTube.   The technique Sundaresh illustrates in his video assumes that the SAS Viya administrator has provided multiple Python profiles that can then be associated with different compute contexts to provide unique programming experiences.  This article will walk you through the steps needed to define those multiple Python and R profiles using the SAS Configurator for Open Source.   The setup I am using a SAS Viya platform deployment of Stable 2023.08 so if you use an earlier release, you may see minor differences along the way.   By following the steps described in Using the SAS Configurator for Open Source to Build Python and R, my initial setup has a default_py profile that uses Python 3.9.15 and a default_r profile that uses R 4.2.3.   Let's suppose that my user community has asked me to create profiles for Python and R that allow them to use the previous releases of Python and R which were 3.8.15 and 4.2.2 respectively so they can compare results of existing programs.   The before state Just so we can put the later changes in context, this is the state of my sas-pyconfig persistent volume before adding additional profiles.  Notice that we have a default_py symlink to Python3.9.16 and a default_r symlink to R4.2.3.  The symlinks are created to match the names of the defined Python and R profiles.   default_py -> /opt/sas/viya/home/sas-pyconfig/Python-3.9.16.1693336494 default_r -> /opt/sas/viya/home/sas-pyconfig/R-4.2.3.1693336494 extlang.xml md5sum Python-3.9.16.1693336494 R-4.2.3.1693336494   Declare the new profile names Assuming you followed the steps in Using the SAS Configurator for Open Source to Build Python and R to get started, the only file you need to edit to create additional profiles is $deploy/site-config/sas-pyconfig/change-configuration.yaml.  This file defines a configmap for the sas-pyconfig job so the order of the defined elements does not matter.   To make things easier to explain and maintain, I am going to rearrange some of the elements to keep each profile definition separate and explain each section in turn.  In actuality, the following sections are all parts of the one change-configuration.yaml file.   At the top of change-configuration.yaml I have the global settings that enable the sas-pyconfig job build both Python and R and most importantly, declare the names of the Python and R profiles I am defining. In addition to default_py and default_r, the new previous_py profile will be used with the older Python release and the new previous_r profile used with the older R release.   apiVersion: builtin kind: PatchTransformer metadata: name: sas-pyconfig-custom-parameters patch: |- - op: replace path: /data/global.enabled value: "true" - op: replace path: /data/global.python_enabled value: "true" - op: replace path: /data/global.r_enabled value: "true" - op: replace path: /data/global.pvc value: "/opt/sas/viya/home/sas-pyconfig" - op: replace path: /data/global.python_profiles value: "default_py previous_py" # Python profile names to be defined - op: replace path: /data/global.r_profiles value: "default_r previous_r" # R profile names to be defined   Define the default_py profile Continuing in change-configuration.yaml, I next have the configuration that defines the default_py profile.  These are just the default values from my 2023.08 deployment.   # default_py profile section - op: replace path: /data/default_py.configure_opts value: "--enable-optimizations" - op: replace path: /data/default_py.pip_install_opts value: "--force-reinstall" - op: replace path: /data/default_py.cflags value: "-fPIC" - op: replace path: /data/default_py.pip_install_packages value: "Prophet sas_kernel matplotlib sasoptpy sas-esppy NeuralProphet scipy Flask XGBoost TensorFlow pybase64 scikit-learn statsmodels sympy mlxtend Skl2onnx nbeats-pytorch ESRNN onnxruntime opencv-python zipfile38 json2 pyenchant nltk spacy gensim pyarrow hnswlib==0.7.0 sas-ipc-queue great-expectations==0.16.8" - op: replace path: /data/default_py.pip_r_profile value: "default_r" # profile of R to use with rpy2 package - op: replace path: /data/default_py.pip_r_packages value: "rpy2==3.5.12" - op: replace path: /data/default_py.python_signer value: https://keybase.io/ambv/pgp_keys.asc - op: replace path: /data/default_py.python_signature value: https://www.python.org/ftp/python/3.9.16/Python-3.9.16.tgz.asc - op: replace path: /data/default_py.python_tarball value: https://www.python.org/ftp/python/3.9.16/Python-3.9.16.tgz   Define the new previous_py profile I want the new previous_py profile to be exactly like the default_py profile except I want it to use Python 3.8.15.  To create the new previous_py profile, I just repeated all of the default_py profile elements being sure to change all instances of default_py to previous_py, and modified the python_signature and python_tarball values.   Because I am including the rpy2 package, I want the older version of Python to use the older version of R so my users can truly replicate their earlier experience, so it is worth special notice that pip_r_profile is going to be based on the previous_r profile that we are adding.   # previous_py profile section - op: replace path: /data/previous_py.configure_opts value: "--enable-optimizations" - op: replace path: /data/previous_py.pip_install_opts value: "--force-reinstall" - op: replace path: /data/previous_py.cflags value: "-fPIC" - op: replace path: /data/previous_py.pip_install_packages value: "Prophet sas_kernel matplotlib sasoptpy sas-esppy NeuralProphet scipy Flask XGBoost TensorFlow pybase64 scikit-learn statsmodels sympy mlxtend Skl2onnx nbeats-pytorch ESRNN onnxruntime opencv-python zipfile38 json2 pyenchant nltk spacy gensim pyarrow hnswlib==0.7.0 sas-ipc-queue great-expectations==0.16.8" - op: replace path: /data/previous_py.pip_r_profile value: "previous_r" # profile of R to use with rpy2 package - op: replace path: /data/previous_py.pip_r_packages value: "rpy2==3.5.12" - op: replace path: /data/previous_py.python_signer value: https://keybase.io/ambv/pgp_keys.asc - op: replace path: /data/previous_py.python_signature value: https://www.python.org/ftp/python/3.8.15/Python-3.8.15.tgz.asc - op: replace path: /data/previous_py.python_tarball value: https://www.python.org/ftp/python/3.8.15/Python-3.8.15.tgz   Define the default_r profile Next, we have the values that define the default_r profile.  These are unchanged from the initial configuration.   # default_r profile section - op: replace path: /data/default_r.cflags value: "-fPIC" - op: replace path: /data/default_r.configure_opts value: "--enable-memory-profiling --enable-R-shlib --with-blas --with-lapack --with-readline=no --with-x=no --enable-BLAS-shlib" - op: replace path: /data/default_r.r_tarball value: https://cloud.r-project.org/src/base/R-4/R-4.2.3.tar.gz - op: replace path: /data/default_r.packages value: "dplyr jsonlite httr tidyverse randomForest xgboost forecast"   Define the new previous_r profile Again, I modeled the new previous_r profile off of the default_r profile, changing only the path values to reference the previous_r profile and the version of R that it builds.   # previous_r profile section - op: replace path: /data/previous_r.cflags value: "-fPIC" - op: replace path: /data/previous_r.configure_opts value: "--enable-memory-profiling --enable-R-shlib --with-blas --with-lapack --with-readline=no --with-x=no --enable-BLAS-shlib" - op: replace path: /data/previous_r.r_tarball value: https://cloud.r-project.org/src/base/R-4/R-4.2.2.tar.gz - op: replace path: /data/previous_r.packages value: "dplyr jsonlite httr tidyverse randomForest xgboost forecast"   Just for completeness, the rest of change-configuration.yaml has only the target definition.   target: version: v1 kind: ConfigMap name: sas-pyconfig-parameters   That completes the changes.  You could, of course, modify the package lists or make other changes to the profiles but for now, let's move on.   Apply the change Save your changes and with the configuration complete, you now need to rebuild the SAS deployment and apply the changes to the cluster.  How you do this is dependent upon the deployment method used with your SAS Viya deployment.   See Modify Existing Customizations in a Deployment for guidance on this task.   If you deployed using the viya4-deployment GitHub project, you should consult the project documentation for guidance.   Execute the sas-pyconfig job If your deployment uses the Deployment Operator or the sas-orchestration deploy method, the sas-pyconfig job will execute automatically and rebuild Python and R with your configured changes.   If your deployment is manually managed, you will need to execute the job yourself by running a command similar to this after applying the updated configuration to your cluster.   kubectl create job sas-pyconfig-adhoc --namespace your-namespace --from cronjob/sas-pyconfig   The after state Let's take a look at the state of the sas-pyconfig volume at the completion of the sas-pyconfig job.   Notice that we now have two Python builds and two R builds, one for each release, and new symlinks whose names match our new profiles.   default_py -> /opt/sas/viya/home/sas-pyconfig/Python-3.9.16.1693436460 default_r -> /opt/sas/viya/home/sas-pyconfig/R-4.2.3.1693436460 extlang.xml md5sum previous_py -> /opt/sas/viya/home/sas-pyconfig/Python-3.8.15.1693436460 previous_r -> /opt/sas/viya/home/sas-pyconfig/R-4.2.2.1693436460 Python-3.8.15.1693436460 Python-3.9.16.1693436460 R-4.2.2.1693436460 R-4.2.3.1693436460   Validate Python Let's make sure the programmers can access both releases.  This little SAS program can be run from SAS Studio and should report that the first PROC PYTHON step uses the default_py profile of Python 3.9.16 while the second step uses the new previous_py profile of Python 3.8.15.  The ERROR message is expected and can be ignored.   /* to use default_py */ options set=PROC_PYPATH='/opt/sas/viya/home/sas-pyconfig/default_py/bin/python3'; options set=SAS_EXT_LLP_PYTHON='/opt/sas/viya/home/sas-pyconfig/default_py/lib/python3.9/lib-dynload'; proc python; submit; import sys print(sys.version) exit(0) endsubmit; run; quit; /* to use previous_py */ options set=PROC_PYPATH='/opt/sas/viya/home/sas-pyconfig/previous_py/bin/python3'; options set=SAS_EXT_LLP_PYTHON='/opt/sas/viya/home/sas-pyconfig/previous_py/lib/python3.8/lib-dynload'; proc python; submit; import sys print(sys.version) exit(0) endsubmit; run; quit;   You should see results such as this.     One special note about this testing approach...the compute server will reuse the first Python subprocess it starts unless you explicitly terminate it with the exit() method.  Without that in the first PROC PYTHON step, both steps will report using the same version of Python.   Validate R Here is a similar program we can use to validate access to both R profiles.  Because the default_r profile is typically configured into the compute servers, you really do not need the first OPTIONS statement but I am including it here for symmetry.    /* use the default_r profile */ *options set=R_HOME='/opt/sas/viya/home/sas-pyconfig/default_r/lib64/R'; proc iml; submit / R; v <- R.Version() print(v) endsubmit; run; quit; /* use the previous_r profile */ options set=R_HOME='/opt/sas/viya/home/sas-pyconfig/previous_r/lib64/R'; proc iml; submit / R; v <- R.Version() print(v) endsubmit; run; quit;   Output from the first step should include: $version.string [1] "R version 4.2.3 (2023-03-15)".   And output from the second step should include: $version.string [1] "R version 4.2.2 (2022-10-31)".   Next steps Now that you know how to create additional Python and R profiles, you can use the technique Sundaresh shows in his Python à la carte: Configure repeatable & reusable Python environments video to create separate Compute contexts for each profile to make it easier for programmers to select a given configuration.   You may also want to check out the SAS Studio Custom steps repository from the SAS Software GitHub repository that can be used to work with Python and R.   Python Virtual Environments R Runner   Related Resources Python à la carte: Configure repeatable & reusable Python environments (YouTube) Python à la carte: Configure repeatable & reusable Python environments (SAS Blogs) R Runner: get from SAS to R through a Python tunnel (SAS Communities) Using the SAS Configurator for Open Source to Build Python and R (SAS Communities) Configuring SAS Viya for Python Integration (SAS Communities) Configuring SAS Viya for R Integration (SAS Communities) Using the SAS Configurator for Open Source to Add Packages to Python and R (SAS Communities) ... View more

In Using the SAS Configurator for Open Source to Build Python and R, I summarized the steps an administrator needs to follow to build open source software for use with the SAS Viya platform. The default configuration of the SAS Configurator for Open Source adds a number of packages we felt users would find most helpful to the core Python and R builds. While the initial list of additional packages provides a great starting point, users will inevitably ask their administrator to add more packages to the builds to support the needs of new projects.   I have fielded a few questions lately asking how to add new packages to existing builds of Python and R builds so let's work through how administrators can do that using the SAS Configurator for Open Source.   Key Steps   Assuming you have existing builds of Python and R you created using the SAS Configurator for Open Source, you should perform these steps to add new packages to Python and R.   Modify $deploy/site-config/sas-pyconfig/change-configuration.yaml to add the desired new packages to the existing list of packages. Update the deployment which will modify the sas-pyconfig cronjob definition to include the new packages. Execute the sas-pyconfig job If the deployment uses the Deployment Operator or the sas-orchestration deploy command the sas-pyconfig job will automatically execute. If using the deploy with Kubernetes commands method, the administrator will need to issue commands to re-run the sas-pyconfig job. Validate user access to the new packages.   Modify the configuration   The first step is to modify $deploy/site-config/sas-pyconfig/change-configuration.yaml and add any additional packages your users need to Python and R.   As an example, I am going to add the cx_Oracle package to the Python build and the caret package to the R build. Neither of these new packages has documented dependencies, but it is a good idea to read the installation documentation for each package you add in case there are dependent packages you need to include.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Note: SAS Viya platform releases 2023.08 and later will include additional changes to change-configuration.yaml. If you are using release 2023.08 or later and your existing $deploy/site-config/sas-pyconfig/change-configuration.yaml was created in an earlier release, you should   Make a backup of your current $deploy/site-config/sas-pyconfig/change-configuration.yaml Copy $deploy/sas-bases/examples/sas-pyconfig/change-configuration.yaml to $deploy/site-config/sas-pyconfig Edit the new change-configuration.yaml to include your earlier modifications as well as any new changes you need to make.   Apply the configuration change   You next need to apply the configuration change you made to update the ConfigMap for the sas-pyconfig cronjob.  Until you do this step, the sas-pyconfig cronjob will continue to build the packages listed before you made your change.   You will need to follow the process necessary for your particular situation depending on the deployment method you employ.     See Modify Existing Customizations in a Deployment for guidance on this task.   If you deployed using the viya4-deployment GitHub project, you should consult the project documentation for guidance.   Execute the sas-pyconfig job   If your deployment uses the Deployment Operator or the sas-orchestration deploy method, the sas-pyconfig job will execute automatically and rebuild Python and R with your configured changes.   If your deployment is manually managed, you will need to execute the job yourself by running a command similar to this after applying the updated configuration to your cluster.   kubectl create job sas-pyconfig-adhoc --namespace your-namespace --from cronjob/sas-pyconfig   What happens when the job runs   When the sas-pyconfig job executes it will detect that there has been a change made to the change-configuration.yaml by comparing its hash with the hash from the previous configuration stored in the md5sum file.  The job will then rebuild Python and R which is when the new packages will be included.   The image below compares the state of the sas-pyconfig persistent volume before sas-pyconfig runs with its state after the job completes. You can see from the lines marked in the 'after change' state that we have new builds for both Python and R, the default_py and default_r links have been updated to reference the new builds, and the md5sum file has been updated so it can detect future changes.       Validate the change   After the sas-pyconfig job completes, you should validate the addition of the new packages. I usually do this by examining the Python and R builds to make sure the new packages were installed and by making sure SAS Viya can reference them.   In my deployment, the Python packages I added will appear in the ./Python-3.8.15.1689776107/lib/python3.8/site-packages directory. The listing below only shows a subset of Python packages I have installed but I can see that the cx_Oracle package has been added.     Similarly, I can do the same for my R build by examining the ./R-4.2.2.1689776107/lib64/R/library directory to make sure the caret package has been added.       Finally, I usually use SAS Studio to validate that the SAS Viya platform can access the new packages. I always try to include in my test one package that was accessible before I made the change as well as any new packages I add.     You do not want to see log messages stating ModuleNotFoundError from Python or 'there is no package' from R from your test as shown below. This indicates that the expected packages have not been added properly. You should examine the log from your last sas-pyconfig job to see if there was an error during the build processes that prevented the installation from completing successfully.     SAS Viya platform releases 2023.08 and later will emit more extensive error reporting in the sas-pyconfig job logs which should provide better notification of package installation issues for administrators.   A word about removing packages...   The steps above focus on adding packages to existing builds of Python and R but the same steps can be used to remove unwanted packages. However, removing packages is a less common request of an administrator as it has the potential to break existing code. Unless there is a significant reason to get rid of an existing package such as it poses a security risk or there are legal implications, administrators should work closely with their user community before the removal of a package to safeguard existing work.     Find more articles from SAS Global Enablement and Learning here. ... View more

Over time, SAS Cloud Analytic Services (CAS) servers accumulate in-memory data as users create SAS Visual Analytics reports, import data for programs, and load data to perform advanced analytics.  When CAS servers stop, whether when individually restarted by an administrator, or when the SAS Viya platform is brought down, all of the data that was previously loaded by users and business processes is unloaded from memory.   One of the tasks all SAS Viya platform administrators must face is to develop a strategy for handling the reloading of CAS tables when CAS servers start to minimize disruption for their SAS Viya user community.   In this post, I will review a few options for SAS Viya administrators to employ as they formulate a reloading strategy.  Chances are high that administrators will need to employ a combination of the following options to reload CAS tables for their users.   Strategy 1: Take advantage of just-in-time loading   Making sure that the CAS tables that back SAS Visual Analytics reports are readily available is often a primary concern for administrators when CAS servers start.  Fortunately, SAS Visual Analytics will automatically load a CAS table for a report viewing user from any CAS library for which the user has LimitedPromote permissions.   Advantages CAS tables are loaded only when needed. Easy for administrators to implement -- just assign LimitedPromote permission for CAS libraries that commonly provide data for reports. SAS Visual Analytics reports work automatically after every CAS start. Potential concerns The 'first viewer' penalty -- the first viewer of a report may have to wait for larger tables to load. The automatic loading only happens for SAS Visual Analytics reports so CAS tables needed for other purposes will have to be managed separately. Although a bit dated, you can read more about how this works in this SAS Communities article.   Strategy 2: Explicitly load tables   If the administrator is aware of certain tables that users rely on being available, they can modify the CAS startup configuration to explicitly load CAS tables after the CAS server starts but before users are allowed to connect to it.   To modify the startup script in the configuration instance, you will first need to add a reference to $deploy/sas-bases/overlays/sas-programming-environment/enable-admin-script-access.yaml in the transformers: section of your $deploy/kustomization.yaml.   Using SAS Environment Manager or the sas-viya command, administrators can configure the sas.cas.instance.config: startup property to include Lua code that explicitly loads CAS tables.  This short section from the SAS documentation describes the startup property.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The administrator would need to modify the startup contents to include a Lua statement like this for each CAS table to be loaded:   ---- Load HR summary table s:table_loadTable{caslib="hrdl", casOut={caslib="hrdl", replication=0.0}, path="hr_summary.csv", promote=true }   Advantages CAS tables can be pre-loaded for any purpose whether that is for reports, analytics, etc. There is no 'first viewer' penalty for CAS tables used for SAS Visual Analytics reports. Frequently used large tables can be readily available for immediate use. Potential concerns Loading extremely large tables might impact CAS startup times. This depends on the CAS library backing data store and whether it supports parallel loading.  See this article for examples. Assumes the administrator knows which CAS tables need to be pre-loaded. The list of CAS tables that need to be pre-loaded may change frequently. There is a risk that the CAS table is loaded but not used. Lua, which may be unfamiliar to some, is the only supported language for table loading instructions.   Strategy 3: Use CAS Table State Management jobs   CAS table state management jobs manage the importing, loading, and unloading of source files in CAS.  SAS provides sample jobs for the Public CAS library that you can copy and modify to act upon other CAS libraries.  CAS tables state management jobs can be quite flexible in terms of selecting a subset of files to load from a given CAS library.   Once defined, CAS tables state management jobs can be run manually in an ad-hoc manner or you can schedule them to recur. This can be beneficial if you have a CAS library with source files that are frequently updated or added.  You can also chain jobs together for convenience purposes.   As far as using this as a re-loading strategy, the administrator can start the CAS server and rely on the next scheduled occurrence of the CAS table state management jobs to take care of loading tables. This works best if CAS servers are started far enough in advance of users accessing SAS Viya for the scheduled jobs to run.   If immediate loading is required, say for an ad-hoc CAS server restart, the administrator can manually execute any number of CAS table state management jobs to load CAS tables from the Jobs page of SAS Environment Manager.   For instructions on how to copy and modify the sample CAS table state management jobs, see this SAS Communities article or the SAS documentation for CAS table state management.   Advantages Multiple source files from a single CAS library can be loaded. Jobs can include filters that load a subset of source files. State management jobs can be scheduled. There is a sample job for unloading CAS tables that have not been used recently.  This can be quite helpful in maintaining CAS servers that are long-lived. Potential concerns There may be a lag between the CAS server starting and the next execution of the scheduled jobs. May require manual execution of the jobs by the administrator.   Strategy 4: Configure State-Transfer for CAS   This strategy is somewhat different as it only helps in cases where a CAS server needs to be restarted while keeping the rest of the SAS Viya platform running.  It does nothing to help with reloading CAS tables from a cold start of the entire SAS Viya platform.   Enabling CAS for state transfer allows the sessions, tables, and state of a running CAS server to be preserved between a running CAS server and a new CAS server instance.  Because CAS tables and sessions are transferred to the new instance, there is no need to reload any data.   Details and instructions for enabling CAS state transfer are available in SAS Viya - CAS Server Life Cycle Management on SAS Communities.   Advantages Minimizes potential disruption for users. CAS tables do not have to be reloaded. Existing sessions tranfer to the new CAS instance. Potential concerns Does not help with reloading tables when the CAS server first starts. Requires a persistent volume to use during the transfer of tables and sessions to the new instance. May briefly elevate cluster resources as the transfer takes place.   Wrapping up   As mentioned earlier, I fully expect that administrators will need to employ a combination of these reloading strategies to properly implement a CAS reloading plan for their user communities.  Administrators will have to weigh different user demands, service level agreement terms, and reasons for reloading CAS tables to determine the best strategy for their situation.   I hope that by describing common options and the advantages each has, administrators can make an informed decision as to the best plan of action for their deployments.   Find more articles from SAS Global Enablement and Learning here. ... View more

Here in the US, it is common for home builders to acquire a few acres of land and then offer to build custom homes.  They usually offer three or four base model homes that are targeted at the needs of the typical home buyer and because the builder knows what materials are needed, the model homes can be built quickly and efficiently.   To satisfy the needs of home buyers with special preferences, builders offer to customize the model homes with any number of options.  Want a screened porch instead of a patio?  Want to upgrade the appliances?  Want premium carpet, or paint, or fixtures? Want to choose custom paint colors instead of beige?  The choices are endless and while some of the options affect the overall price, others are merely preferences and may not alter the price at all.   In much the same way, SAS provides the SAS Viya platform with a default set of options and settings that we feel will be appropriate as a starting point for most customers, a model deployment, if you will.  Customers can start with the default deployment and then, over time, change it in an almost limitless number of ways.   A frequent driver of change is a desire to improve performance, whether that is throughput for SAS programs, model training, loading data into CAS, or simply starting the SAS Viya platform. Given the number of tuning options SAS Viya provides, one of the hardest questions we get is, "Do you have any tuning recommendations for us?"   Fortunately, SAS provides the SAS Viya Platform Administration: Tuning guide which offers tuning recommendations and considerations for when certain tuning options make sense.   Based on Experience   The SAS Viya Platform Administration: Tuning guide focuses on tuning recommendations related to performance and scalability across a number of areas. The recommendations have been collected from a wide range of customer experiences, testing scenarios, and feedback from SAS consultants and technicians.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Read the Considerations   As an administrator, I appreciate how most of the tuning topics include a considerations section that describes when tuning or scaling might be appropriate and how following the recommendation could impact a deployment.  Understanding when to apply certain tuning recommendations is crucial because not every tuning recommendation will be needed in every case and some of the recommendations have the potential to affect the overall cost of managing a deployment.     Variety of Topics   As of this writing, the SAS Viya Platform Administration: Tuning guide offers tuning points for a number of topics ranging from the cluster hardware, to the topology of your CAS server, to configuration of the SAS Programming Run-time servers, to configuration settings for PostgreSQL and JDBC connections.   I won't try to list every tuning item here but just to give you a taste of what's covered...   Provisioning Hardware for Performance includes Storage considerations Machine specifications for processing nodes Resource monitoring tools Tuning machine resource requests. Tuning the CAS Server includes Considerations for changing from the default non-distributed CAS to a distributed CAS server Adding additional CAS workers Hardware considerations for CAS_DISK_CACHE. Tuning Programming Resources and Programs covers Storage considerations for programming pods (e.g., SASWORK) Configuring reusable compute servers Configuring pools of reusable, pre-started compute servers Advice for coding options to optimizing performance. Tuning the PostgreSQL Server describes Tuning Memory and CPU resources Various Tuning parameters and when to use each one Options for tuning the SAS Backup processing for the PostgreSQL database. Tuning SAS Visual Analytics includes Performance-related setting that can affect report performance Guidance for avoiding out-of-memory issues.   Keep coming back   I encourage you, as a SAS Viya platform administrator, to revisit the SAS Viya Platform Administration: Tuning guide from time to time, The guide receives frequent updates as our SAS technical writers are made aware of new learnings.  And you are always welcome to submit your own ideas for improvement by utilizing the Feedback menu item at the top of all SAS documentation pages.     Thanks for reading.  Based on some recent experiences, it became apparent that many administrators were unaware of the tuning guide, so I thought it was worth a short article to advertise its existence.   Find more articles from SAS Global Enablement and Learning here. ... View more