@(#) LSARC Questions Version 2.0u @(#)LSARC 1.30 07/12/07 __________________________________________________________________ Copyright 2007 Sun Microsystems, Inc. __________________________________________________________________ 0. Remind us: 0.1 The case number for this project? LSARC 2008/054 0.2 This questionnaire is for an [X] Inception Review (request combined Inception/Commitment) 0.3 Name(s) of person(s) answering the questions? Steve McKinty (steve.mckinty@sun.com) Tim Read (tim.read@sun.com) 0.4 Are these case materials considered public or confidential? Public 1. What specifically is the proposal that we are reviewing? Oracle DataGuard (ODG) plugin for Solaris Cluster Geographic Edition. 1.1 The case owner will need to put a 1 to 4 paragraph description at the top of the Opinion document. Suggest text for it. Please be specific about deliverable components and their interfaces. Solaris Cluster Geographic Edition (SCGE), codenamed Odyssey, is a management framework which integrates Solaris Cluster with one of several data replication products from various suppliers, including Sun. Each replication product is controlled by a specfic module in the form of a Cacao MBean, which plugs into the SCGE framework. This project describes the replication module for Oracle DataGuard (ODG). ODG is an application-based replication mechanism which enables an Oracle database called the Primary to send transaction information to remotely-located database (the Secondary) for security and backup purposes. 1.2 Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", "micro" or "patch" change and why? (See the release type definitions in http://sac.eng.sun.com/BestPractices/release_taxonomy.html ) This is a minor update to an existing product. 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? Existing supported replication technologies operate at the level of disk (or volume) blocks. A single database transaction, initiated by an SQL command, can result in modifications to dozens if not hundreds of blocks. Not only is this inefficient, but it requires special handing of logfiles to ensure that transaction semantics are maintained. Oracle users are a very large part of the Solaris Cluster market, which brings $60m/year of income to Sun. Recent disasters (floods, 9/11) have made people more aware of the need for disaster recovery in their data centres, and ODG is the mechanism of choice for Oracle. We need to support it in order to maintain, and grow, our Oracle user base. The success will be judged in terms of successful SCGE deals for Oracle users. 3. The plan: 3.1 Who (what groups in what business units) are working on it? Solaris Cluster, part of the Solaris organization. 3.2 What is the current status? Beta code is available. 3.3 Has a design review been done? The internal cluster ARC (CLARC), made up of senior Solaris Cluster architects, has reviewed the design and approved it. 3.4 What Product Approval Committee (PAC) do you expect to approve this project? As well as the Solaris Cluster PAC, the JES PAC is the usual PAC for global Solaris Cluster issues. 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? None. 4.2 What non-Sun projects does this project depend upon? Oracle 10g RDBMS 4.3 What other projects depend on this one? None 4.4 What other active projects at Sun are related to your project, and how are they related? Solaris Cluster provides the core application management infrastructure for the Oracle 10g RDBMS. 4.5 What future projects should be started or avoided to help your project succeed, and why? N/A 4.6 What open source communities does this project interact with? The Open HA Cluster community. OHAC was created to promote the use and development of HA clustering solutions including Solaris Cluster. http://opensolaris.org/os/community/ha-clusters/ohac/ 5. What technical approach has been selected by the project? The project creates a new module for SCGE that interfaces to the Oracle Data Guard broker system. See section 4 of the "Design Specification", DocRef: TS/TR-07-4.X.Y "Oracle Data Guard replication in Odyssey". (where X.Y is the latest version) The document can be found at: http://hadoc.france/cgi-bin/getdoc?ref=TS-TR-07-4 6. How is the project delivered into the system? SCGE is an unbundled product, delivered as a set of Solaris packages which are installed on a core Solaris Cluster installation. Each replication module delivers as two packages (user and root), and ODG will do the same. Installation is optional, and only necessary for clusters where SCGE management of ODG is required. There will be two packages: SUNWscgrepodg and SUNWscgrepodgu Both will be installed by default in /opt. 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. The project will work on all platforms supported by core Solaris Cluster. This includes SPARC and x64, with Solaris 9 and 10, and the current opensource (SXDE) release. Note that this may be limited by support restrictions placed by Oracle, over which we have no control. 7.2 Are Solaris components expected to work on SPARC and x86? Yes. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No. 8. Compatibility and Interoperability 8.1S OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? On any Solaris version supported by Solaris Cluster 3.2 (or above) i.e. S9u8 and later. S10u4 and later. It should also run on SXDE. 8.1.2 Does it run on Linux? What distribution(s) and version(s)? No. Core Solaris Cluster does not support Linux. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? The release train of SCGE tracks that of Solaris Cluster, so any varations there will be dealt with during normal development. It is possible that updates to Oracle, or to JES shared components, may necessitate a corresponding update to SCGE. 8.2S Do Solaris components depend on OS features not in the core OS (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages or clusters must be installed first (if the "core" set of packages is insufficient)? Do the packages express those dependencies explicitly? We use the following commands and packages: SUNWcsu /bin/cat /bin/chown /bin/date /bin/dirname /bin/grep /bin/head /bin/ksh /bin/ksh /bin/ls /bin/rm /bin/sed /bin/sleep /bin/su /bin/tail SUNWesu /bin/awk SUNWpkgcmdsu /bin/pkgparam SUNWsccomzu /usr/cluster/lib/sc/scds_syslog SUNWscdev /usr/cluster/bin/hatimerun /usr/cluster/bin/pmfadm /usr/cluster/bin/scha_cluster_get /usr/cluster/bin/scha_resource_get /usr/cluster/bin/scha_resource_setstatus /usr/cluster/bin/scha_resourcegroup_get The packages do reflect these dependencies. We also use the following Oracle commands: ${ORACLE_HOME}/bin/oracle (to ascertain Oracle uid, via ownership) ${ORACLE_HOME}/bin/srvctl ${ORACLE_HOME}/bin/dgmgrl Since Oracle software isn't packaged, we cannot check the dependencies, per se. 8.3 Do Solaris components use any system interfaces, commands, or features not in POSIX or the Single Unix Specification? What is the minimum version of those standards required? (POSIX.1-1990, UNIX98, UNIX2003?) No 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base? What is the minimum LSB version required? N/A 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) We (currently) use only the following Oracle 10g commands: ${ORACLE_HOME}/bin/oracle (to ascertain Oracle uid, via ownership) ${ORACLE_HOME}/bin/srvctl ${ORACLE_HOME}/bin/dgmgrl 8.5 What internationalization (I18n) issues are involved? What languages *can* be supported by localization without modifying the base product, whether or not a localization is currently planned? What I18N interfaces will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext(), X/Open catgets(), GNU gettext? What items and interfaces are (or are not) being internationalized? This project does not have a UI. It does define properties that are used by the CLI and GUI for inout and output. These are all defined in standard files for L10N. The SCGE product is L10Ned in Simplified Chinese and Japanese. As with its parent, Solaris Cluster, a waiver was granted for the other Tier 1 languages: French, German and Spanish. Other langauges can be added by L10N if required. 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/x86 ABI, POSIX, Open Group standards, IETF RFCs, national or international standards. Include version numbers where applicable. No 8.7 Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? This is the first release of the module, backwards compatibility is not an issue. For future releases we intend to support a single version of skew as a minimum, i.e. version 'n' will interoperate with at version least 'n+1'. Only one version of the software can be installed on a system at any one time. The module will only allow inter-operability between Oracle versions that Oracle support. Currently the module only supports 10g, but it is expected that the module would support 10g/11g mixtures on the same instruction set based clusters. (Oracle don't support replicating from Solaris/SPARC to Solaris/x64) 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? No. 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? No. 8.10 What components (e.g., libraries or packages) are shared with other projects or products? 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? Yes. 8.12 Device Drivers: N/A. Userspace (Java/ksh) only. 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. See "Illustration 1" in section 4.1 of the "Design Specification", DocRef: TS/TR-07-4.X.Y "Oracle Data Guard replication in Odyssey". (where X.Y is the latest version) The document can be found at: http://hadoc.france/cgi-bin/getdoc?ref=TS-TR-07-4 9.2 Interface Table: Include Imported and Exported Interface Tables showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). Interfaces are not just function calls. Include user interfaces (graphical, browser based, character based), configuration files, XML DTD's, database schemas, network protocols, port numbers, etc. The Oracle Data Guard module interfaces to the user and to Oracle Data Guard as follows: CLI Browser ^ (PERL) (Lockhart) | | | | Existing SCGE interfaces \ / | Core SCGE V (CACAO) | ----------------- Project private interface | control script (KSH) / \ A --- --- B | | Oracle Sun Cluster (CLI) (SCHA_*) EXPORTED INTERFACES: Proposed Specified Former Stability Interface Stability in what Classification Name Classification document? or Other Comments ------------------ ------------- -------------- -------------------- There are no new exported interfaces from this module. ------------------ ------------- -------------- -------------------- IMPORTED INTERFACES: In addition to making use of the existing SCGE private interfaces, the ODG module also uses the following: Proposed Specified in Former Stability, Interface New Stability what case no. Contract Number, Name Classification &/or document? or Other Comments ------------------ -------------- -------------- -------------------- scha_* Committed SUNWscdev package scds_syslog Uncommitted SUNWsccomzu package srvctl Volatile Oracle CLI dgmgrl Volatile Oracle CLI ------------------ ------------- -------------- -------------------- 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). There will be two packages: SUNWscgrepodg and SUNWscgrepodgu SUNWscgrepodg Contains components to be installed on the root filesystem of all systems. SUNWscgrepodgu Contains "user" compnents, which could be mounted from a remote system. 9.4 Package manifest: See the latest version of "Product Packaging and Installation Sun Cluster Geographic Edition R2 (Odyssey)" Current Version: TS/TR-03-169.2.3 http://hadoc.france/cgi-bin/getdoc?ref=TS-TR-03-169 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? 10.1S Do they conform to PSARC/1999/645 command syntax guidelines, an extension of the Single Unix Specifications rules? Are any of the "CLIP" extensions to the SUS guidelines used? This module does not implement a user interface. It is called from the SCGE framework, which in turn but relies on the CLI and GUI interfaces from the core SCGE project, which was approved by UIRB review 2004/628 and LSARC 2004/281. 10.3 Environment Variables: No environment variables from the users shell are used. 10.3.1 What environment variables are used? Describe values and semantics. N/A 10.3.2 What is the default behavior if the environment variable is not set? N/A 10.3.3 What environment variables are set? None 10.4 For Solaris, Linux, or other Unix programs, what are their exit status values? What nonzero status values have what meanings? The odg_control file has a number of non-zero exit codes, however, it only ever returns these to the CACAO framework that called the script. The messages that relate to these non-zero returns are kept in the odg.properties resource file. 10.5S Signals issued? Signals caught? (See "man signal".) What are their semantics? None 10.6 Device drivers directly used (e.g. /dev/audio)? None 10.7S .rc/defaults files, Java properties, GNOME GConf keys or other resource/configuration files or databases? Describe any files used between invocations. N/A 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? The odg_control script uses /tmp/.GeoInput.$$ and /tmp/.GeoOutput.$$ files to provide input to the dgmgrl command. The input file is created read root only and then changed to owner Oracle. It contains an unencrypted database DBA password. It is deleted immediately on use, effectively thus: (cat /tmp/.GeoInput.$$ ; rm /tmp/.GeoInput.$$ ) | dgmgrl The output files are deleted after use, although occasionally they can remain if the shell script was kill -9 before a clear up was possible. The information contain is less sensitive being only the status output from dgmgrl. 10.9 Does it use any locking files? Does it use Solaris locking facilities? No. 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? The odg_control command is always executed locally by the CACAO ODG module. 10.11S Solaris/Linux/Unix Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. N/A 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? N/A 10.11.2 With what -R options will executables be built? N/A 10.11.3 Does it use any static libraries? N/A 10.11.4 What libraries does your project export? N/A 10.12 Does your project use or ship database or persistent storage software? If not, skip the rest of this section. No. 10.13 Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? It uses whatever version of Java the underlying CACAO framework supports. It makes no additional demands on Java. 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? Via the JES installer (or it's replacement), or by pkgadd. 11.2 How will the project's deliverables be uninstalled? Via the JES uninstall mechanism, or pkgrm. 11.3 How will the project's deliverables be configured and reconfigured? Through internal interfaces invoked from the SCGE framework. 11.4 Does it need installation within any global system tables? Does your package edit existing files in a common directory (/etc/vfstab for example)? If so, how do you remove your edits when your package is removed? If your package is reinstalled over itself, does it recognize that the edits are already there or does it make all new entries? No. 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? No. 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? Yes. 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? (BASEDIR) Yes. 11.7.1 Has your project changed or introduced any package procedural scripts (postinstall, preremove, etc)? No. The postinstall and preremove/postremove scripts are all empty/null. 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? N/A 11.9 How does a new version of your package upgrade a prior version? The SCGE framework is shut down (this does not impact the operation of the services being managed) and the old packages are uninstalled. New packages are then installed, and the SCGE framework restarted. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No. 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? N/A 11.12 How is it started? For a daemon: does it use SMF (if on Solaris) or inetd? If not, why not? If SMF, does it comply with the SMF best practices in http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=SMF.bp ? N/A 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? N/A 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? /tmp should occasionally be checked for old .GeoOutput.$$ files. These can safely be removed. They are typically only ~200 - 300 bytes each. 11.15 Can administration be done from a remote machine? How? The Solaris Cluster GUI is a Lockhart-based browser interface, and all SCGE management functions are available through it. 11.16 Can all GUI administration also be performed without the GUI? How? All SCGE operation can be controlled via a CLI. 11.17 What command or scripting language is used? Korn shell. 11.18 Does the project include runtime license checking? No. 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, technology royalty structure, or open source license requirements? No. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? If not, say "NONE" and remove all this section's subsections. NONE. 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. 13.1 Exported Library APIs and ABIs exposed to customers N/A 13.2 Protocols (public or private, including RPCs) N/A 13.3 Drag and Drop: what objects and what are the semantics? N/A 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? N/A 13.5 Files used as an interface, e.g. Resources, config files, etc. N/A 13.6 Significant file formats, names, syntax, and semantics? Is there an /etc/magic entry for any new file format? What will file(1) say? N/A 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) N/A 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? N/A 13.9 Other External Interfaces? Oracle CLI commands only (srvctl and dgmgrl) 13.10 Brainstorming Significant Internal Interfaces N/A 13.11 Protocols (public or private) N/A 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions N/A 13.13 Files and their Formats N/A 13.14 Do any internal interfaces save state across invocations? Yes, but only to the Solaris Cluster CCR using the mechanisms provided already by SCGE. 13.15 Other Internal Interfaces? N/A 14. Questions for Every Interface: These questions should be asked for every one of the project's interfaces; the answers are therefore often listed in Section 9.2 (Don't repeat.) Only the interesting answers are normally discussed. The module only depends on the output of two Oracle commands to various command formats so the result can be parsed: A. srvctl ${ORACLE_HOME}/bin/srvctl status database -d ${database_name} expected output is of the form: Instance foo1 is running on node ppyrus1 Instance foo2 is running on node ppyrus2 B. dgmgrl dgmgrl -silent << EOF connect sys/oracle@foo EOF where could be: show configuration enable database switchover to failover to parsable output for the first command is similar to: DGMGRL> show configuration Configuration Name: foo.com Enabled: NO Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: foo - Primary database foodr - Physical standby database Current status for "foo.com": DISABLED 14.1 Propose the stability/commitment classification of the interface -- Committed (formerly Public, Stable or Standard), Uncommitted (formerly Unstable), Volatile, Project Private, etc. -- per the SAC Interface Taxonomy document at http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp The imported Oracle interfaces used are defined by an organization which outside of Sun's control, and can therefore only be defined as Volatile. 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. Oracle controls the key command line interfaces here. 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? There is no 'specification' per se, beyond the user documentation. 14.3.2 Is the specification complete enough for a re-implementation? If the output format were to change, the key pieces of code to be modified to re-parse the output. 14.3.3 Will the project deliver to customers documentation for the interface? No. 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? N/A 14.4 Interface Versioning and Projected Evolution N/A 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. N/A 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? Sun and Oracle regularly test each new version of their respective products, and certify specific versions as compatible. The same approach will be continued here. Should a change be made, the companies have procedures in place, including regular meetings to ensure a timely communication of the change, to ensure that impact to customers is minimized. 15. Performance and Scalability: ODG is the most efficient way to replicate an Oracle database, so the key reason for this project is to provide the best performance. The actual performance seen during replication is entirely dependent on things like the network links, database complexity and system performance. The only time the performance of this specific module is relevant is during the switchover process, and at that time the major defining factor will be the ODG switchover time. Any additional SCGE overhead will be insignificant. 15.1 What are the performance goals of the project? How were they evaluated (or how will they be)? On what type of test platform? How will performance regressions be identified? N/A. The performance of the Data Guard is not related to the performance of SCGE. (See 15) 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? N/A 15.3 Resource Consumption: N/A 15.3.1 Attempt to describe resource consumption scaling, even crudely. For example, if each client consumes 1MB of memory, you could say: Memory_required = 1MB * Nclients N/A 15.3.2 Which resources are likely to be bottlenecks? Oracle itself will be the dominant factor in resource consumption. SCGE will be negligible in comparison. 15.4 Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? The probe scripts used by the Solaris Cluster resource for determining the health of the replication can be slow in responding. This is entirely dependent on the responsiveness of the dgmgrl "show configuration" command. 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? Is it prepared for multi-thread & multi-core systems like Niagara and Opteron? N/A 15.6 What is the impact on system performance (positive or negative)? Negligible. 15.6.1 What is the average memory usage or working set of this component? N/A 15.6.2S How much of this is shared/sharable by other apps? Part of CACAO and existing SCGE footprint. 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? 15.8 Will it require large files/databases (for example, new fonts)? N/A 15.9 Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? N/A 15.10 What are the project's effects on boot time requirements? N/A for Solaris boot time, but it can slow the restart time for SCGE due to the time taken to verify the ODG configurations. Again this is down to dgmgrl responsiveness. 16. Security: Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. See section 4.2.3 "Changes to Odyssey to support password property handling", DocRef: TS/TR-07-4.X.Y "Oracle Data Guard replication in Odyssey". (where X.Y is the latest version) The document can be found at: http://hadoc.france/cgi-bin/getdoc?ref=TS-TR-07-4 16.1 What security issues do you address in your project? There is a need for access to a sysdba Oracle database user password. The project uses the mechanisms referenced above to avoid exposing this password in clear text on the command line. It is only ever held in clear text in a superuser-access-only file for long enough for it to be consumed as input. 16.2 What security concerns might customers or reviewers have? Users may not be keen to supply a sysdba Oracle user password (the equivalent of a Solaris root password) but unfortunately there is no alternative. 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? No. 16.4 How are particularly security-critical data like passwords treated? When stored in the Solaris Cluster CCR they are obfuscated using a simple ASCII code to hex mapping. No encryption method would be any more secure once the source is available in the Open Source world. The method hides it from the casual observer who might chance to see the information on the screen should the superuser have displayed the relevant CCR table on the screen. Without root access it will otherwise be unavailable. With root access, the database and thus the password would be compromised anyway. 17. Availability and Serviceability 17.1 How will it respond to failures? The fundamental reason for this project is to provide integrated management of a High Availability infrastructure in a Disaster Recovery environment. Sun serviceability engineeering performed an assessment of the previous SCGE release to determine the Product Serviceability Health Index (PSHI), and commented that "PSHI is 95%, very good" 17.2 How does your project deal with network failures (including partition and re-integration)? SCGE is specifically intended to to alert an administrator to this situation, and this project provides a way to switch to a backup Oracle database in such circumstances. 17.3 Can it save and restore state? Is any special action required if the filesystem is rolled-back to previous state (such as via ZFS or other filesystem snapshot technologies)? N/A 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? Yes, all configuration information is held in the Solaris Cluster CCR. 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng.sun.com/)? Yes, indirectly. Solaris Cluster participates in FMA, and this project integrates with Solaris Cluster. 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? Yes to both. 17.7 How will patches be installed? The framework will be shutdown (without impact service from manages databases). Patches can then be applied through the normal Solaris procedures, and the framework restarted. 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, Microsoft Windows, MacOS X, AIX, HP/UX, etc.)? No. Solaris Cluster has no such plans, and conversion of the core product would be a prerequisite for us. 18.2 How does it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? Non-issue. 18.3 How will the project provide services to other projects? As a management framework it does not interact directly with such projects. 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? None. 18.3.2 Current or planned Java Beans, especially J2EE? Project is implemented as a Cacao MBean. 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) None. 18.4 What is its relationship (or difficulties) with . . . 18.4.1 the Internet? Web Services? None. 18.4.2 Java? J2EE? Application Servers? Written in Java. 18.4.3 "Network of Things" (thin clients, portable devices, cell phones, wireless networking, kitchen appliances with IP addresses?) None. 18.4.4 Multimedia? None. 18.4.5 Networked storage (SANs, NAS) Project interfaces to Oracle, all storage access is abstracted by the Oracle database. 18.4.5 Infiniband? None. 18.4.6 Network identity services? None. 18.4.7 Virtualized environments (Xen, Zones, VMWare)? None at present. When Solaris Cluster completes implementation of the "Oracle RAC on Zones" project we will revist this. 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) None Any issues outstanding from previous reviews (or the case's mail archive)? 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? 3 hours 20.3.2 Do you think it was time well spent? Just about. 20.3.3 How many engineer hours went into answering this questionnaire alone? 3 hours 20.3.4 Comments on this questionnaire should be mailed to lsarc-chair@sac.eng.sun.com. 20.3.5 Comments on your case owner, the review process, or the experience may be placed here if they're not too personal, may be mailed to the chair or arc-chairs@sac, or may be expressed to John Plocher (x87604), or your divisional CTO.